Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents



The IRWS V3 v3 documentation is not complete. Please contact  if if you have questions about V3 v3 usage.



This guide describes the Identity Registration Web Service (IRWS) API V3v3.  Documentation for IRWS V2 is also available .  IRWS can be used to to register an identity with the Identity Registry.  IRWS offers a "RESTful" programmatic interface. It exposes Identity Registry source information as addressable resources via the uniform HTTP interface; authorized clients may retrieve (GET), create (PUT), update (POST) and delete (DELETE) representations of these resources through the REST API.

Example Use Cases

  • The UW Payroll system needs to add an employee affiliation to an existing UW NetID (e.g. a student has been hired as an employee and needs an employee identity associated with their UW NetID)
  • You need to read affiliation details associated with a UW NetID
  • You want to set a Private Access Code (PAC) for a user so they can obtain a UW NetID  


An SSL client certificate is required for access (see section Certificate Authentication below). Request IRWS Access

IRWS V3 Swagger Documentation

Swagger documentation for IRWS v3 can be found at Identity Registration Web Service REST API v3.


The application that uses this service must support:

  • Authentication with X.509 certificates
  • HTTP GET, PUT, POST, and DELETE requests
  • JSON content type only





All interactions with IRWS are through the following base URLs.   Customer Customer testing is generally done in the Eval environment. The Dev environment is currently dedicated to Workday integration development and testing. It is only available to Workday integration partners.reserved for the IAM development team. 

Excerpt Include
_IRWS_Base URLs V2V3
_IRWS_Base URLs V2V3



Due to the sensitive nature of the information in IRWS, there are several layers of access control. The requirements for access are generally more stringent than for other services on campus.

To access IRWS you need:

  • A DNS name and static IP address.  
  • A certificate issued by the  UW Services CA

DNS Name and Static IP Address

These are available from UW Network Operations by emailing  See  Information on DNS Names  and   Information on Static IP Addresses .  Generally, you can request both in the same email to Network Operations.  Make sure to request that your UW NetID be associated with the DNS name so you can request certificates for it, and that the IP address reverse resolve to the DNS name.  See the example request below.  

No Format
I would like to request a Static IP address and associated DNS name.  
The IP address of my machine right now is xx.xx.xx.xx.  I would like 
the DNS name  
Please associate my UW NetID with the DNS name so I can request 
certificates for it.  Lastly, the IP address should reverse resolve to the DNS name.  

Certificate Authentication

Authentication is by certificates issued from the UW Services CA, and by hostname (DNS name) or IP address.  The IP address of the client is verified in addition to the certificate.  Connections will automatically be allowed if the IP address of the client reverse resolves to the subject name of the certificate presented.  For special cases, you can request additional hostnames or IP addresses be allowed to authenticate with the certificate (if a hostname is specified, the IP address of the client must reverse resolve to the hostname given). 

Certificate Authorization

To request access to IRWS you must open a support request in UW Connect. Please send an email to Try to be specific about what application you are working on, what you are trying to do, and what resources you need access to. To speed up routing, you can include "Please route to the Identity and Access Management team" in your request. Your certificate may not be authorized for all of the functions described in this documentation.

Supported HTTP Request Headers

IRWS supports a set of standard and custom HTTP headers that can be used by a client to express options. All the listed request headers are optional and all can be combined.


  • imprecise - Overrides default PUT behavior to behave like a POST if the record already exists. This is the default behavior for some resources.
  • pretend - Reports what would happen if the request was carried out, but the changes are not committed. Useful for testing.
  • pretty - By default, IRWS returns a payload as a single line of text. For human readability you can specify this option to get a pretty-printed representation of the data.
  • reflect - Useful for PUTs and POSTS, specifying reflect will cause IRWS to return the current state of the resource. This is the default behavior for the  source  and  social  resources.
  • Example: Option-List: imprecise reflect

Supported URI Parameters

HTTP headers are the preferred way for an application to express the IRWS options it needs. For convenience, some of the options described above can be communicated via parameters in the URI. This may be useful for user interactive testing with a browser or the curl utility. All parameters are optional and different options may be combined in one URI. Definitions and availability are provided in the previous section. 

  • -type=[json]
  • -actas=permit=[application name]
  • -attribute=[attribute1+attribute2...]
  • -imprecise
  • -pretend
  • -pretty
  • -reflect
  • Examples:
    • GET 

IRWS V3 Swagger Documentation

Swagger documentation for IRWS V3 can be found at: Identity Registration Web Service REST API V3


Identity records are associated with a resource.  A GET on the base URL will return a list of all top-level resources for which your client is authorized. Documentation is provided for the resources listed in the table below.  (TBD: Update links/pages for v3.)



Account The Account resource allows an authorized client to create, read, update, delete, and perform other actions related to account entities.  
CategoryThe Category resource allows an authorized client to...
DsubscriptionThe Dsubscription resource allows an authorized client to...
NameThe Name resource allows an authorized client to read and update source-independent names associated with person entities.
PdsentryThe PDS Entry resource allows an authorized client to read Person Directory data.
PersonThe Person resource allows an authorized client to create, read, update, delete, and perform other actions related to person entities.  
RegidThe Regid resource allows an authorized client to manipulate attributes associated with regids.
SocialThe Social resource allows an authorized client to create, read, and update social identities. 
SubscriptionThe Subscription resource allows an authorized client to...

Return Codes

IRWS uses standard HTTP return codes, as well as a few special ones.  Most Most errors will return a JSON payload with the error class containing the code and message properties.   

Return Code





200OK (the GET, PUT, or POST was successful)Resource (JSON)
400Invalid identifier type providedError (JSON)


404Identifier provided did not match any recordsError (JSON)


Method Not AllowedError (JSON)
406Content type not supported 


500Internal Server ErrorNone


Not ImplementedNone
503Service UnavailableNone