Skip to main contentDownload App

The Doximity API

Take the friction out of registration


Authentication and Verification

The Doximity API allows partners to utilize Doximity’s verification engine to verify the identity of a user and allow the user to authenticate using their Doximity credentials. That’s one less username and password for a doctor to remember; less friction during registration and confirmation that the user is a clinician.

Bear in mind that the Doximity API is intended for authenticating and identifying verified users. We do not allow broad querying of our database.

OmniAuth Strategy

If you have a Ruby on Rails application, you can integrate with Doximity easily using OmniAuth with Doximity's OmniAuth Strategy. See the documentation in the for a quickstart guide.

OAuth Authorization and OpenID Connect

Doximity uses the server-side flow of the OAuth 2.0 to authenticate, and OpenID Connect to identify. Those in conjunction enable users to authenticate and verify their identity against the Doximity national directory of healthcare providers using standard industry-standard protocols.

We'll be using the Authorization Code Grant Flow, suitable for web applications running on the server-side, as well as with mobile and client-side applications (using the PKCE extension).

Important considerations:

  • We highly recommend not building OAuth 2 and OpenID clients in-house, instead of using a known and supported OAuth 2 code libraries and OpenID code libraries, as the complexity and nuances of the OAuth 2 specification can be overwhelming.
  • All requests must be sent over HTTPS, validating SSL certificates.
  • The client secret and all tokens transmitted are considered sensitive as passwords, and must not be shared or distributed to untrusted parties, or saved as unencrypted plain texts on code repositories.

Step 1: Dynamically fetch the configuration files

We implement OpenID Connect Discovery, which allows for easier dynamic configuration of OAuth and OpenID libraries. Your application should regularly fetch the URL below in order to download the proper URLs and settings to be used when integrating with Doximity:


It will return a payload similar to the following one:

  "issuer": "",
  "authorization_endpoint": "",
  "token_endpoint": "",
  "check_session_iframe": "",
  "end_session_endpoint": "",
  "jwks_uri": "",

We also implement OAuth 2.0 Authorization Server Metadata, which can inform your app what we support and what scopes are available for use:


It will return a payload similar to the following one:

  "issuer": "",
  "authorization_endpoint": "",
  "token_endpoint": "",
  "revocation_endpoint": "",
  "userinfo_endpoint": "",
  "scopes_supported": [
  "token_endpoint_auth_methods_supported": [
  "response_types_supported": [
    "code id_token"
  "token_endpoint_auth_signing_alg_values_supported": [
  "ui_locales_supported": [

Step 2: Redirect the user to the Doximity OAuth Dialog

On your application, use one of the provided following graphics in order to link to Doximity:

If you choose, you can also send users directly to the verification URL on Doximity by using the prompt=create parameter (described later on), and using the following graphical buttons:

width: 140pt, height: 30pt

You may also adjust the width of the button to match the width of other buttons on screen, as long as the button's contents are not distorted. Download PSD source file

The URL should be constructed dynamically using the "authorization_endpoint" returned at Step 1 and should look similar to the following one:


Here's an overview of each parameter on the example above:

  • client_id (required): public identifier for your application, obtained once Doximity approves your submission.
  • response_type=code (required): tells the authorization server that the application is initiating the authorization code flow.
  • redirect_uri (required): tells the authorization server where to send the user back to after they approve the request.
  • code_challenge (required): a URL-safe base64-encoded SHA256 hash of the secret. It prevents authorization codes from being stolen in transit back to your application. For more information, please refer to the PKCE extension.
  • code_challenge_method=S256 (required): should also be present when using PKCE. The S256 method is the only one supported.
  • scope: takes a space-delimited list of available scopes. We recommend that you use the smallest possible scope to minimize the friction of registration for your site. By default, we only allow the "openid" scope to be used, as it enables OpenID Connect id_token to be returned (more details below).
  • state: random string generated by your application. You should check that the same value was returned after the user authorizes the app. This is used to mitigate cross-site request forgery attacks.
  • prompt: forces interaction for the user to go through. Options are:
    • "" (default): not setting this parameter or setting an empty string is the default behaviour, and will not force any specific user interaction.
    • none: redirect back to your URI if user is already authenticated, otherwise returns an error.
    • login: force the login interface even if user is already authenticated.
    • consent: force the consent interface even if user already consented to your application.
    • create: land user directly on a page to let them create their account, per Initiating User Registration via OpenID Connect.
  • display: how we should display the authentication and consent user interface pages to the End-User. Options are:
    • page (default): responsive user interface for mobile applications, phones, tablets and desktops.
    • popup: lightweight interface, suitable to a minimal popup. For mobile apps, prefer not using this option and instead relaying on the default one.
  • response_mode: following the OAuth 2.0 Multiple Response Type Encoding Practices, we handle:
    • query (default): authorization response parameters are encoded on the query string added to the redirect_uri (e.g.
    • fragment: authorization response parameters are encoded on the fragment added to the redirect_uri (e.g.
  • nonce: random string generated by your application. It binds the OpenID tokens with your requests, serving as token validation parameter and is introduced from the OpenID Connect specification. This is used to mitigate replay attacks.
  • id_token_hint: if the user logged in before and you have their previous id_token, pass it inside this parameter in order to provide better user experience, pre-filling the email address so they can re-sign in more quickly.
  • response_mode: by default, it's set to "query", so the authorization response parameters are encoded in the query string added to the redirect_uri when redirecting back to the Client. If set as "fragment", the authorization response parameters are encoded in the fragment added to the redirect_uri when redirecting back to the Client.

This URL will then redirect the user to a login page, where they will be able to login or create and verify their identity, before being redirected back to you when they are correctly logged in with Doximity.

Step 3: The user is prompted to authorize your application

If the user does not yet have a Doximity account, they will be taken through Doximity’s verification process to create credentials and verify their identity as a clinician. If the user has a Doximity account but is not logged in, they will log in using their existing credentials. If the user is already logged in to Doximity, they will be presented with the authorization screen. The user must approve your site's access to their Doximity account.

Step 4: The user is redirected back to your site

If the user authorized your application, the user will be redirected back to the redirect_uri you provided when the operation was initiated. In our example, it will be something like this:


Here's a brief explanation on each returned parameter:

  • code: the authorization code generated by the authorization server. This code is short-lived, lasting only a few minutes.
  • session_state: used by OpenID Connect Session Management, only returned if scope=openid was present in Step 2.
  • state: the same value that your application initially set in the request. Your application is expected to check that the state in the redirect matches this one.

If the user did NOT authorize your application, the user will be redirected to:


Step 5: Exchange the code for a User Access Token and OpenID Connect identifier

After the user has authorized your application, you can make a request to exchange the code you received on the previous step for a user access token. You make this request through a post-call with the appropriate Authorization headers and parameters.

With the code retrieved from step 4, and with the "token_endpoint" from step 1, build a request similar to this one:

POST /oauth/token HTTP/1.1
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Authorization: Basic BASE64ENCODED_VALUE_HERE


You must include an authorization header with basic authentication, using the client ID and client secret as username and password respectively. In order to build this header manually, you can URL encode both username and password independently, join both using a ":" as a separator (i.e. clientID:clientSecret), base64 encode the joined string, resulting in the "Authorization" header on the example above.

You are also required to use the PKCE extension by setting code_verifier on this token endpoint request.

Here's an overview of each parameter on the example above:

  • client_id (required): your client ID. It's required if you're not sending the client ID on the Authorization header.
  • grant_type=authorization_code (required): indicating that we are using the authentication code grant type.
  • code (required): the code you received from the authorize endpoint in step 3
  • redirect_uri (required): this must be the EXACT same value from step 1
  • code_verifier (required): PKCE code verified that your application generated at the beginning of the flow.

The server will respond with the access token in the following format.

  "access_token": "ACCESS_TOKEN",
  "token_type": "bearer",
  "expires_in": 1800,
  "refresh_token": "REFRESH_TOKEN",
  "scope": "openid",
  "id_token": "eyJhbGc[...omitted for brevity...]"

Here's an overview of each parameter on the example above:

  • access_token: the access token that's bound to the logged-in user's account. Remember that this information is sensitive just like a password, so store it encrypted on your database (for server-side applications) or on the device's keychain (for mobile applications), make sure you never log it anywhere and take other measures to avoid it from being leaked into wrong hands.
  • token_type: in this case, it will be always "bearer".
  • expires_in: represents the number of seconds that the token will be valid. After the token expires, a new token will need to be issued. Tokens can also be revoked, in which case applications need to handle "401 Unauthorized" responses and request a new token when necessary.
  • refresh_token: used to refresh existing authentications against Doximity in the background without the need of user intervention. How to make a refresh token call to Doximity
  • scope: scopes granted by the user per your request in which this access token has access to.
  • id_token: OpenID Connect identification token, providing a secure way to transmit the user's identification. More information about it further below.

Step 6: Identify the authenticated user

At this stage, all we need to do is to parse the OpenID Connect identification token received in the previous step, as it contains the user's identity.

According to the OpenID Connect Core specification, the id_token received on step 5 is a JWT with a signature mechanism. First, you'll need to parse the JWT, which you can experiment with using It will return three distinct sections:


  "alg": "RS256",
  "kid": "cbd6ffe0-fa7b-4cfd-8256-e2cf3f260514"


  "iss": "",
  "sub": "00000000-0000-0000-0000-000000000000",
  "aud": [
  "azp": "YOUR_APP_CLIENT_ID",
  "exp": 1600313852,
  "iat": 1600312119,
  "auth_time": 1600312052,
  "at_hash": "5naHMnnHJ0I[...omitted for brevity...]"


By using the "jwks_uri" URL on the configuration file on Step 1, you'll be able to use the "kid" parameter set on the header to identify the JSON Web Key Set used to sign this JWT. Once you have the proper public certificate, compare it against the payload with the signature here to confirm that this user identification wasn't tampered with. You can find more information about it on both JSON Web Key (JWK) and the OpenID Connect Core section 10.1 regarding Asymmetric Signatures.

Finally, the user identification you need can be found on the sub (Subject) parameter, "00000000-0000-0000-0000-000000000000" in this example. Use that information to identify the user currently logged in.

Step 7: Refresh the user's authentication (optional)

After the expires_in time given in the response in step 5, in seconds, the user's access token will expire. You can receive a new one without redirecting the user using the refresh token received along with the access token.

Build a request similar to this one:

POST /oauth/token HTTP/1.1
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Authorization: Basic BASE64ENCODED_VALUE_HERE


Here's an overview of each parameter on the example above:

  • Authorization header (required): your client ID and secret, written as "clientID:clientSecret", base64 encoded.
  • grant_type=refresh_token (required): indicating that we are using the refresh token grant type.
  • refresh_token (required): the refresh token you received from the token endpoint in step 5
  • scope: a space-delimited list of scopes. You cannot add new scopes here, only repeat the same ones from the original authorization or request a subset of it. If you need to request authorization to new scopes, you'll need to restart from Step 2.

The server will respond with the access token and a new refresh token in the same format as in step 5. Both the refresh token in this request and the original access token associated with it are immediately revoked, and won't work anymore.

Token termination

Per our terms of service, you must ensure that user tokens are not leaked in any sort or form. To decrease the chance of that happening, make sure to revoke and expire tokens once they are no longer needed. The most important use case is when a user logs out from your platform, but also is useful when they unlink their account from Doximity, then a user removes their account from your platform, or then you want a user to re-connect to Doximity for any reason.

Token revocation

If you're running a service where users logging out can run parallel processes in the background (such as on an SPA or on a mobile client), use our implementation of the OAuth 2.0 Token Revocation (RFC 7009) described as the example below:

POST /oauth/revoke HTTP/1.1
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Authorization: Basic BASE64ENCODED_VALUE_HERE


Here's an overview of the parameter on the example above:

  • Authorization header (required): your client ID and secret, written as "clientID:clientSecret", base64 encoded.
  • token (required): the access token or refresh token you want to expire. You're free to chose which one you want to send to us, as we'll revoke the associated tokens (so sending a refresh token will revoke both refresh token and access token).

The server will respond with an HTTP 200 header with no content.

Session Management

Validating User Session Status

When an End User is authorized with OpenID in Step 2, the user will be redirected to your callback URI with a session_state param in Step 4. Along with the check_session_iframe endpoint returned from Step 1, you can verify an End User's session state using our implementation of OpenID Connect Session Management described in the example below:

First, add an iframe to your page pointed at the check_session_iframe URI:

<iframe id="op" src="" style="display: none"/>

Then, use some form of this Javascript on your page to poll the session_state endpoint:

// Compose the message
var message = client_id + " " + session_state;
var targetWindow = document.getElementById("op").contentWindow;
targetWindow.postMessage(message, "");

Here's an overview of the variables in the example above:

  • client_id : public identifier for your application, obtained once Doximity approves your submission and used in previous authorization steps.
  • session_state : The OpenID Connect Session Management Session Code, as returned in Step 4.

Note: The Javascript poller must be from the same origin as the redirect_uri used when authenticating the End User in Step 2. Otherwise, Doximity will always return a "changed" response.

Finally, add a receiver to your page to collect responses from the Doximity provider:

function receiveMessage(event) {
  var response =

  switch (response)
    case "changed":
      // The user's session state has changed
    case "unchanged":
      // The user's session state has not changed
    case "error":
      // Something went wrong

window.addEventListener("message", receiveMessage, false);

User Logout

If you want to log out a user that you have an OpenID Connect token for, you can redirect the End-User's User Agent to our implementation of OpenID Connect RP-Initiated Logout 1.0 described in the examples below:

Note that the endpoint you'll use must be the same as you received as the end_session_endpoint from Doximity's configuration in Step 1.

Using a POST form:

POST /oauth/logout HTTP/1.1
Content-Type: application/x-www-form-urlencoded; charset=UTF-8


Or using a GET request:


Here's an overview of the parameters on the examples above:

  • id_token_hint (required): The signed OpenID Connect identification token, retrieved in step 5.
  • post_logout_redirect_uri (required): The URI that Doximity will redirect the End User's User Agent to after logout. It must match the post-logout URI your app was registered with.
  • state (optional): If provided, this param will be passed on as the `state` param on the redirect URI.

The server will respond with an HTTP 302 header and redirect the user to the post-logout redirect URI.

Requesting User Info

Doximity implements the OpenID Connect UserInfo endpoint at the endpoint defined by userinfo_endpoint from the configuration files retrieved in Step 1. It can be used to get information about the authorized user as shown in the example below:

GET /oauth/userinfo HTTP/1.1
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Authorization: Bearer ACCESS_TOKEN_HERE

Note: If your authorization is bound to a public key according to the DPoP spec, use the following headers:


Here's an overview of the parameter on the example above:

  • Authorization header (required): The non-expired, non-revoked End User's access token
  • Dpop header (optional): The newly-generated DPoP proof JWT

Just like in Step 6, the server will respond with a JWT, with the following parts


  "alg": "RS256",
  "kid": "cbd6ffe0-fa7b-4cfd-8256-e2cf3f260514"


  "iss": "",
  "aud": [
  "sub": "00000000-0000-0000-0000-000000000000",
  "name": "John Doe",
  "given_name": "John",
  "family_name": "Doe",
  "middle_name": "",
  "credentials": "MD",
  "profile_photo_url": "",
  "specialty": "Anesthesiology"


See the overview in step 6 for information about the JWT signature.

Here's an overview of each parameter on the example above, and the scope that is required to receive it:

  • iss (No scope required): The issuer of the JWT token, which will be
  • aud (No scope required): The audience the JWT token is intended for. This will be both the issuer itself, as well as the requesting application.
  • sub (No scope required): The End User's unique identifier in Doximity. This will be an RFC4122 compliant UUIDv4.
  • name (profile:read:basic): The End User's full name.
  • given_name (profile:read:basic): The End User's first name.
  • family_name (profile:read:basic): The End User's last name.
  • middle_name (profile:read:basic): The End User's middle name.
  • credentials (profile:read:basic): The End User's medical credentials.
  • profile_photo_url (profile:read:basic): The URL for the End User's profile picture.
  • specialty (profile:read:basic): The End User's medical speciality.

Share Button

By adding a share button to your website you enable your users to share content easily and directly on Doximity. There are two ways to add the button. The first requires appending a JavaScript tag while the second stands on its own. We recommend the first option unless you have a specific reason you cannot support JavaScript.

How to add the share button to your website

  1. Add the following code to your website. Note the class name "doximity-share-button". It is important you include this so that the JavaScript can find your buttons and enhance them. Set the "href" attribute to "".
  2. You may add 3 parameters to your button to populate fields with known values. They are: url, message and subject and are represented as data-url, data-message and data-subject. All are optional.
  3. Load the JavaScript by including the tag as demonstrated below. Note carefully the "async" option.
<a href=""
   data-message="Check out this article"
   data-subject="Measles in Ohio"
   aria-label="Share via Doximity">
<script async src="//" charset="utf-8"></script>

Simple share button example

If you know you do not want to add the JavaScript, you can create a direct link to the share endpoint on Doximity. Remember that query parameters need to be escaped.

<a href="
   aria-label="Share via Doximity">
   Share via Doximity

Rate Limiting

Doximity has different rate limits for authenticated users, unauthenticated users, and OAuth applications.

For OAuth applications, you can make up to 5,000 requests per hour. You can check the returned HTTP headers of any API request to see your current rate limit status. With every request, you will receieve the following headers that outline your current limits.

Header NameDescription
X-Rate-Limit-LimitThe maximum number of requests that the consumer is permitted to make per hour.
X-Rate-Limit-RemainingThe number of requests remaining in the current rate limit window.
X-Rate-Limit-ResetThe time at which the current rate limit window resets in UTC epoch seconds

Once you go over the rate limit you will receive a 429 Too Many Requests status code with an error response:

HTTP/1.1 429 Too Many Requests
Date: Mon, 29 Sep 2014 23:55:21 GMT
Status: 429 Too Many Requests
X-Rate-Limit-Limit: 5000
X-Rate-Limit-Remaining: 0
X-Rate-Limit-Reset: 1412034908

  "message": "API rate limit exceeded. Please check the documentation for details.",
  "documentation_url": ""

You can also check your rate limit status without incurring an API hit at /api/v1/rate_limitThe response contains:

  "limit": 5000,
  "remaining": 4999,
  "reset": 1372700873

Staying within the rate limit

If you are using session cookies or OAuth, and you are exceeding your rate limit, you can likely fix the issue by caching API responses or using conditional requests. You may also find that only fetching new data for those users that have recently signed into your site may also reduce the amount of requests you need to make.

If you’re still exceeding your rate limit, please contact us to request a higher rate limit for your OAuth application.


We ask that you honor the rate limit. If you or your application repeatedly abuses the rate limits we will blocklist it. If you are blocklisted you will be unable to get a response from the Doximity API. If you or your application has been blocklisted and you think there has been an error you can contact the email address on our Support page.

Doximity API Terms of Use

Thank you for helping to build the healthcare web and for using Doximity’s APIs. Doximity makes its application programming interfaces (Doximity APIs” or “APIs”) available to you to facilitate the development of innovative medical applications using Doximity data and developer tools. If you want to use the Doximity APIs outside the scope of these Terms and Conditions, or to build and/or distribute enterprise applications outside your own company (e.g. use the APIs to build an Application that you distribute to other companies), please contact our Business Development Team.

By using one or more of the Doximity APIs, you and, if applicable, the company you represent (collectively, “you”) accept and agree to be bound by the following terms and conditions (the “Terms of Use” or “Terms”). It is important that you read these Terms as they form a legal agreement between you and Doximity, Inc. (“Doximity”, “we”, or “us”).

In addition to the content in this document, the following are incorporated into the Terms (and references to “Terms” shall mean this document and those incorporated by reference):

  1. The Doximity User Agreement, which is located at
  2. The Doximity Privacy Policy, which is located at
  3. The Platform Guidelines, which are located at the Doximity Developer documentation site and
  4. The Branding Guidelines, which are also located at the Developer documentation site.

In the event of any conflict between the content in this document and the documents incorporated by reference, this document shall control with respect to your use of the APIs. If you disagree with any of the provisions in these Terms, do not click that you agree to them, and do not accept, access or use the APIs.

Doximity may remove your API access at any time, and routinely does so on applications that have had no user interaction in the last 3 years.

Doximity reserves the right, from time to time, with or without notice to you, to change these Terms in our sole and absolute discretion. The most current version of these Terms can be reviewed on the Doximity developer documentation site at anytime and supersedes all previous versions. By using the Doximity APIs after changes are made to the Terms, you agree to be bound by such changes. Your only recourse if you disagree with the Terms, or changes to the Terms, is to discontinue your use of the APIs. Accordingly, we recommend you review these Terms periodically.

1 Description, Licenses, and Restrictions

1.1 Description of Doximity APIs.

The APIs consist of programmatic web APIs and associated tools and documentation that allow you to create software application(s) or website(s) (your “Application”) using certain data and content from the Doximity website at (“Website”), made accessible by Doximity in its sole discretion (the “Content”). While Doximity strives to have its APIs available continuously, it cannot guarantee any up-time for any Doximity developer resource, including the APIs.

1.2 Developer Accounts and Access Codes.

To obtain the necessary security keys, secrets, tokens, passwords and/or other credentials to access the APIs (collectively, “Access Codes” or “API Keys”), you must create a account through Doximity’s developer portal at: or by contacting the Doximity Business Development Team (“Developer Account”). You are responsible for maintaining the secrecy and security of your Access Codes, and all activities that occur using your Access Codes, are your responsibility. In order to maintain accurate information (including a current email address and other required contact information) related your account, you must keep your Developer Account information up-to-date.

1.3 APIs License Grant.

Subject to the terms and conditions in these Terms, we grant you a limited, non-exclusive, non-assignable or non-transferable license under Doximity’s intellectual property rights during the Term to use the APIs to develop, test, and support your Application, and to distribute or allow access to your integration of the APIs within your Application to end users of your Application. You have no right to distribute or allow access to the stand-alone APIs.

1.4 Brand Features License Grant.

Subject to the terms and conditions of these Terms, we grant you a limited, non-exclusive, non-assignable and non-transferable license during the Term to display our trade names, trademarks, service marks, logos and domain names that we make available to you in our discretion via the Branding Guidelines available on our Developer Portal (collectively, “Brand Features”) to promote or advertise your integration of the APIs in your Application. You agree that your use and display of the Brand Features will at all times be consistent with the Branding Guidelines, and any other branding, trademark, or similar guidelines included in the Platform Guidelines. In particular, you agree not to display our Brand Features in any way that is misleading, defamatory, infringing, libelous, disparaging, obscene, or otherwise objectionable to Doximity, or in a way that suggests we have created, sponsored, or endorsed your Application or its content.

1.5 Restrictions.

In addition to other restrictions contained in these Terms, you agree not to do any of the following, unless expressly permitted by Doximity in these Terms or in writing by Doximity:

  1. Use a fraudulent Doximity information to register as a Doximity developer. You must accurately reflect the professional information of the actual developer requesting the license, including an accurate description of the current title and company.
  2. Allow anyone other than you to access your Developer Account.
  3. Sell, transfer, sublicense or otherwise fail to protect the confidentiality of the APIs, Access Codes, or content posted or available in areas of the Developer Portal that require Access Codes.
  4. Modify or attempt to circumvent the Access Codes.
  5. Obtain or use more than twenty-five (25) Access Codes, either through one or multiple developer accounts. Please contact our Business Development Team at: to discuss options to exceed this limit.
  6. Require your users to obtain their own Access Code to use your Application.
  7. Use your Developer Account or Access Codes to build and/or distribute enterprise applications outside your own company (e.g. use the APIs to build an Application that you distribute to other companies).
  8. Request or publish information impersonating a Doximity user, misrepresent any user or other third party in requesting or publishing information;
  9. Provide functionality that proxies, requests or collects Doximity user names or passwords; or
  10. Obfuscate or hide your deployment or use of any Doximity buttons, sign-in functionality, consent or authorization flows from your users.
  11. Allow any third party, including other users, to see information obtained from another user’s Doximity network or through another user’s view of our Website or the Content;
  12. Obtain, display or use more data through the APIs than is minimally required to run the Application created using the particular developer key;
  13. Store Doximity user data other than the Member Token or OAuth Token for any Doximity user, with the exception of a user’s profile data when given explicit permission by the owner of the profile as set forth in 3.4, below. User profile data obtained in accordance with this section and 3.4 below may not be updated without the user’s subsequent consent;
  14. Use the APIs or Brand Features for any illegal, unauthorized or otherwise improper purposes, or in any manner that would violate these Terms (or any document incorporated into the Terms), or breach any laws or regulations, or violate any rights of third parties, or expose Doximity or its members to legal liability in your use of the APIs;
  15. Combine content from the APIs with other Doximity data obtained through scraping or any other means outside the official Doximity APIs. This includes acquiring Doximity data from third parties;
  16. Remove any legal, copyright, trademark, watermark or other proprietary rights notices contained in or on materials you receive or access pursuant to these Terms, including the APIs, the materials posted at the Developer Portal, and our Website;
  17. Sell, lease, share, transfer, sublicense any Content obtained through the APIs, directly or indirectly, to any third party, including any data broker, ad network, ad exchange, or other advertising or monetization-related party.
  18. Charge, directly or indirectly, any incremental fees (including any unique, specific, or premium charges) for access to Doximity’s Content or your integration of the APIs in your Application;
  19. Use the Content in any advertisements or for purposes of targeting advertisements (whether such advertisement appear in your Application or elsewhere);
  20. Submit content that falsely expresses or implies that such content is sponsored or endorsed by Doximity;
  21. Use the Content for generating advertising, messages, promotions, offers, or for any other purpose other than, and solely to the extent necessary for, allowing end users to use the returned Content in your Application;
  22. Implement features or business practices that harms the professional reputation, relationships, or professional ecosystem of Doximity members.
  23. Copy, adapt, reformat, reverse-engineer, disassemble, decompile, translate or otherwise modify the APIs, Access Codes, our Website or any Content displayed on it, including the a user’s Public Profile including its URL, or any of our other services, through automated or other means;
  24. Use the APIs in an Application that competes with products or services offered by us;
  25. Interfere with or disrupt Doximity services or servers or networks connected to Doximity services, or disobey any requirements, procedures, policies or regulations of networks connected to Doximity services;
  26. Use any robot, spider, site search/retrieval Application, or other device to retrieve or index any portion of Doximity services or collect information about users for any unauthorized purpose;
  27. Download, scrape, post, or transmit, in any form or by any means, any part of our Website or Content other than Content that you post as part of your Application;
  28. Transmit any viruses, worms, defects, Trojan horses, or any items of a destructive nature through your use of the APIs;
  29. Use the APIs in an Application that contains or displays or promotes any of the following: spyware, adware, or other malicious programs or code, counterfeit goods, items subject to US embargo, hate materials (e.g. Nazi memorabilia) or materials urging acts of terrorism or violence, goods made from protected animal/plant species, recalled goods, any hacking, surveillance, interception, or descrambling equipment, illegal drugs and paraphernalia, unlicensed sale of prescription drugs and medical devices, the sale of tobacco or alcohol to persons under twenty-one (21) years of age, pornography, prostitution, body parts and bodily fluids, stolen products and items used for theft, fireworks, explosives, and hazardous materials, government IDs, police items, unlicensed trade or dealing in stocks and securities, gambling items, professional services regulated by state licensing regimes, non-transferable items such as airline tickets or event tickets, non-packaged food items, or weapons and accessories;
  30. Use the APIs for purposes where their failure could lead to death, personal injury, or severe property or environmental damage;

1.6 Support and Modifications.

We may provide you with support or modifications for the APIs in our sole discretion. We may terminate the provision of such support or modifications to you at any time without notice or liability to you. We may release subsequent versions of the APIs and require that you use such subsequent versions. Your continued use of the APIs following a subsequent release will be deemed your acceptance of modifications.

1.7 Fees.

The APIs are currently provided for free, but Doximity reserves the right to charge for the APIs in the future. If we do charge a fee for use of the APIs or any developer tools and features, you do not have any obligation to continue to use the Doximity’s developer resources.

1.8 Monitoring.

You agree to provide and assist Doximity in verifying your compliance with this Agreement by providing us information about your Application, including providing us access to it and/or other materials related to your use of the APIs. If, in Doximity’s sole discretion, you do not demonstrate full compliance with this Agreement, we may restrict or terminate your access to the APIs.

1.9 Usage Limitations.

Doximity may limit the number of network calls that your Application may make via the APIs, and/or the maximum Content that may be accessed, or anything else about the APIs and the Content it accesses as Doximity deems appropriate in its sole discretion. The usage limitations can be found in the Doximity developer portal at Doximity may change such usage limits at any time. In addition to its other rights under these Terms, Doximity may utilize technical measures to prevent over-usage and/or stop usage of the APIs by an Application after any usage limitations are exceeded. If no limits are stated in the Platform Guidelines, you nevertheless agree to use the APIs in a manner that, as determined by us in our sole discretion, exceeds reasonable request volume or constitutes excessive or abusive usage.

1.10 Security Measures.

Your networks, operating system and the software of your web server(s), routers, databases, and computer systems (collectively, “System” or “Systems”) must be properly configured to Internet industry standards as required to securely operate your Application. You will not architect or select Systems in a manner to avoid the foregoing obligation. You must promptly report any security deficiencies in or intrusions to your Systems that you discover to Doximity in writing via email to or subsequent contact information posted in the Developer Portal. You will work with Doximity to immediately correct any security deficiency, and will disconnect immediately any intrusions or intruder. In the event of security deficiency or intrusion involving the Application, you will make no public statements (i.e. press, blogs, bulletin boards, etc.) without prior written and express permission from Doximity in each instance.

1.11 Doximity Independent Development.

You understand and acknowledge that Doximity may be independently creating applications, content and other products or services that may be similar to or competitive with your Application, and nothing in these Terms will be construed as restricting or preventing Doximity from creating and fully exploiting such applications, content and other items, without any obligation to you.

2 Proprietary Rights

2.1 Doximity Property.

As between you and us, we own all rights, title, and interest, including without limitation all intellectual property rights, in and to, the (i) APIs, and all elements, components, and executables of the APIs; (ii) the Content available from the APIs; (iii) our Website; and (iv) our Brand Features (collectively, the “Doximity Materials”). Except for the express licenses granted in these Terms, Doximity does not grant you any right, title or interest in the Doximity Materials. You agree to take such actions, including, without limitation, execution of affidavits or other documents, as Doximity may reasonably request to effect, perfect or confirm Doximity’s rights to the Doximity Materials.

2.2 Feedback.

You have no obligation to give us any suggestions, comments or other feedback (“Feedback”) relating to the Doximity Materials. However, we may use and include any Feedback that you voluntarily provide to improve the Doximity Materials and/or any other of our products, services or technologies. Accordingly, if you give Feedback, you agree that we may freely use, reproduce, license, and distribute such Feedback. You also agree not to provide Feedback that you know is subject to any intellectual property claim by a third party or any license terms which would require products or services derived from such Feedback to be licensed to or from, or shared with, any third party.

2.3 Application.

You represent and warrant to Doximity that, excluding Doximity Property, you have the right to use, reproduce, transmit, copy, publicly display, publicly perform, and distribute your Application, and that use by Doximity and its users of your Application shall not violate the rights of any third party (e.g., copyright, patent, trademark, or other proprietary right of any person or entity), or any applicable regulation or law, including the laws of any country in which your Application is made available. Except to the extent your Application contains Doximity Property (and then only with respect to the Doximity Property), Doximity claims no ownership or control over your Application. During the term of these Terms you hereby grant to us a paid-up, royalty-free, nonexclusive, worldwide right and license, under all of your intellectual property rights, to: (i) use, perform, and display your Application and its content for purposes of marketing, demonstrating, and making your Application available to users and (ii) link to and direct users to your Application. Following the termination of these Terms, Doximity shall remove all references and links to your Application from the Doximity website and service.

3.1 Doximity’s Privacy Policy.

Doximity’s collection and use of personal information from its users and developers is governed by Doximity’s Privacy Policy, available at and incorporated by reference into these Terms, with the exception that Doximity may reveal personal information about developers for attribution purposes, handling inquiries from users or potential users, and other purposes Doximity reasonably deems necessary pursuant to these Terms. You understand and agree that Doximity may access, preserve, and disclose your personal information and your developer account details if required to do so by law or in a good faith belief that such access, preservation, or disclosure is reasonably necessary to comply with legal process or protect the rights, property and/or safety of Doximity, its affiliates or partners, its users, or the general public.

You will post a policy complying with the Digital Millennium Copyright Act (DMCA) and respond promptly to notices of alleged copyright infringement involving your Application.

You will (a) maintain your own user agreement and privacy policy applicable to users of the Application (your “Policies”), (b) comply with your Policies, (c) prominently identify and link to your Policies at those locations where users may opt to download or access your Application, and (d) promptly notify us of any breaches of your Policies by you or users of the Application. Your privacy policy will be at least as stringent and user-friendly as Doximity’s. Before obtaining information from your users of the Application, you will obtain their informed consent by informing them what information you collect and how it will be used and/or shared.

3.4 Data Storage and Conversion Limits.

3.4.1 Prohibition on Copying and Storage.

You may not copy, store or cache any Content returned or received through the APIs, including data about users, longer than the current usage session of the user for which it was obtained, except for the alphanumeric user IDs (Member Tokens) which we provide you for identifying users or any individual member’s authentication token (OAuth Token) which we provide you when a Doximity user authenticates your Application to his Doximity account.

3.4.2 Exceptions.

You may store the Member Token and the OAuth Token until the earlier of:

  • Your ceasing using the APIs;
  • The Doximity user uninstalls your application or directs you to delete the user’s information; or,
  • We terminate your use of them for breach of these Terms.

The restrictions of this section do not apply to user profile data received through a one-time call through the APIs that a user explicitly permits you to collect and store, provided that you obtain the user’s consent through the technical and user-interface specifications provided by Doximity, and that any subsequent update to the profile data only be done with the user’s explicit consent. PLEASE NOTE: a) User profile data does not include information about a user’s connections, which may not be copied or stored; and b) you may only use stored profile data for the benefit of the Doximity user that granted you permission to access it.

3.4.4 Removal of Doximity User Data from Your System.

Also, you must remove all data collected with the user’s consent upon request by the user, when the user uninstalls your Application, or when the user closes his or her account with you. The restrictions of this section also do not apply to “Independent Data,” which means data that users provide directly to you and that is separately entered, uploaded, or presented to you by the user of your Application.

4 Marketing and Publicity

4.1 Your Marketing and Publicity.

You may promote your Application, including talking to traditional and online media and your users about your Application, so long as you do so truthfully and without implying that your Application is created or endorsed by Doximity (or otherwise embellishing your relationship with Doximity). However, you may not issue any formal press release via traditional or online media referring to Doximity without Doximity’s prior consent, unless expressly allowed in the Guidelines for Use of Doximity Brand Features.

4.2 Doximity’s Marketing and Publicity.

We may publicly refer to you, orally or in writing, as a licensee of the Doximity APIs and we may publish your name and/or logo (with or without a link to your Application) on our Website, in press releases, and in promotional materials without your prior consent.

5 Confidentiality

The term “Doximity Confidential Information” means any information of or relating to Doximity that becomes known to you through disclosure, observation or otherwise, and that either is designated as confidential by Doximity or that is not generally known or readily ascertainable to the public, including, without limitation, nonpublic information regarding Doximity’s APIs and Doximity’s products, services, programs, features, data, techniques, technology, code, ideas, inventions, research, testing, methods, procedures, know-how, trade secrets, business and financial information and other activities. All Doximity Confidential Information remains the property of Doximity, and no license or other right in any Doximity Confidential Information is granted hereby. You will not disclose any Doximity Confidential Information to any third party, and will take all reasonable precautions to prevent its unauthorized dissemination, both during and after the term of these Terms. If you are a corporate entity, you will limit your internal distribution of Doximity Confidential Information to your employees and agents who have a need to know, and will take steps to ensure that dissemination is so limited. You will not use any Doximity Confidential Information for the benefit of anyone other than Doximity. Upon Doximity’s written request, you will destroy or return to Doximity all Doximity Confidential Information in your custody or control. In addition to the terms of this provision, you and Doximity will continue to be subject to any non-disclosure agreement that you and Doximity have entered into separately. This provision will survive any termination of these Terms.

6 Term and Termination

6.1 Term.

The term of these Terms of Use shall commence on the date upon which you agree to the Terms and shall continue in force thereafter, unless modified or terminated as provided herein.

6.2 Doximity Termination; Suspension; Discontinuance.

We may suspend or terminate your use of all or any of the APIs at any time if we believe you have violated these Terms, the User Agreement, the Platform Guidelines, or, in our sole discretion, we believe the availability of the APIs in your Application is not in our or our users’ best interests. We may discontinue the availability of some or all of the APIs at any time for any reason. We may also impose limits on certain features and services or restrict your access to some or all of the APIs or our Website. All of our rights herein may be exercised without prior notice or liability to you.

6.3 Your Termination.

You may terminate the agreement under these Terms for any reason or no reason at all, at your convenience, by closing your account or ceasing use of the APIs.

6.4 Effect of Termination.

Upon termination of the agreement between you and us under these Terms, (a) all rights and licenses granted to you will terminate immediately, (b) any and all payment obligations, if any, will be due, (c) you will promptly destroy Doximity Confidential Information in your possession or control, and (d) unless we agree otherwise in writing or as stated in these Terms, you must permanently delete all Content or other data which you stored pursuant to your use of the APIs, except as expressly permitted by these Terms of the Platform Guidelines. Doximity may request that you certify in writing your compliance with this section. No liability shall be created for either party by the mere fact of termination of the agreement under these Terms. The following sections of these Terms shall survive termination: Sections 1.5, 1.8, 1.11, 2, 3, and 5-10.

6.5 Remedies.

You acknowledge that your breach of these Terms may cause irreparable harm to Doximity, the extent of which would be difficult to ascertain. Accordingly, you agree that, in addition to any other remedies to which Doximity may be legally entitled, Doximity shall have the right to seek immediate injunctive relief in the event of a breach of these Terms by you or any of your officers, employees, consultants or other agents.





9 Indemnification

You agree to hold harmless and indemnify Doximity, and its affiliates, and their respective directors, officers, agents, and employees, advertisers or partners, from and against any third party claim arising from or in any way related to your use of any Doximity Materials, violation of these Terms of Use or any other actions connected with your use of the Doximity APIs, including any liability or expense arising from all claims, losses, damages (actual and consequential), suits, judgments, litigation costs and reasonable attorneys’ fees, of every kind and nature.

10 General Terms

10.1 Governing Law; Attorneys Fees.

These Terms will be governed by and construed in accordance with the laws of the State of California as such laws apply to contracts between California residents performed entirely within California. Any action or proceeding arising from or relating to these Terms must be brought in a federal court in the Northern District of California or in state court in San Mateo County, California and each party irrevocably submits to the jurisdiction and venue of any such court. In the event of litigation between the parties arising out of or related to these Terms, the prevailing party will be entitled to recover its attorneys’ fees and costs incurred.

10.2 Interpretation.

The term “include” (and all of its variants) when used in these Terms will be interpreted to be followed by the clause “without limitation” in all cases. You agree that Doximity has sole discretion in determining the interpretation of the meaning of these Terms, including determining your compliance with these Terms.

10.3 Export Laws.

You shall comply with applicable export laws and regulations of the United States with respect to any technical materials you receive pursuant to these Terms.

10.4 Waiver.

The failure of Doximity to exercise or enforce any right or provision of these Terms shall not constitute a waiver of such right or provision.

10.5 Severability of Terms.

If any provision of these Terms is found by a court of competent jurisdiction to be invalid, the parties nevertheless agree that the court should endeavor to give effect to the parties’ intentions as reflected in the provision, and the other provisions of these Terms remain in full force and effect

10.6 Applicability and Entirety of Terms.

These Terms do not apply to you if you and Doximity have executed a written API License Agreement, in which case such Agreement applies. In all other cases, these Terms apply to you, they constitute the entire agreement between you and us with respect to the subject matter herein, and they supersede any and all prior proposals (oral and written), understandings, representations and other communications between you and us.

10.7 Relationship Between the Parties.

Nothing in these Terms will be construed as creating a partnership or joint venture of any kind between the parties and neither party will have the authority or power to bind the other party or to contract in the name of or create a liability against the other party in any way or for any purpose.

10.8 Assignment.

You may not assign these Terms, in whole or in part, without Doximity’s prior written consent. Any assignment in violation of this section is null and void.

10.9 Headings.

The section headings in these Terms are for convenience only and have no legal or contractual effect.

Doximity API Branding Guidelines

Doximity permits its third party developers and partners (“you”) to use its name, trademarks, logos, web pages, screenshots and other brand features (the Doximity “Brand Features”, “Marks” or “logos”) only in limited circumstances and as specified in these Guidelines. By using Doximity’s Marks, you agree to adhere to these Guidelines and specifically to the Use Requirements and Terms below. If you have a separate agreement with Doximity that addresses use of the Doximity brand, that agreement shall govern your use of the Doximity Marks.

Our Trademarks

Doximity is a registered trademark of Doximity, Inc.

You should include this attribution, as applicable, with your other trademark and copyright notices.

Use of the “Doximity” Name in Text

When referring to our company, the full name is Doximity, Inc.

When referring to our services, the Doximity name should be written as one word and used as an adjective followed by a description of our services in a form similar to the following examples:

  • Doximity® Profile
  • Doximity® API

The Doximity name should always be accompanied by either the ® or ™ symbol.

Logos For Use By Third Party Developers

You may use the following buttons on your site when linking to the Doximity OAuth authentication flow:

Additional API logos are pending. Please contact us at

Logos For Use By Media

As a member of the media, you may use the logos available here to report on Doximity’s business. These logos may not be altered, combined with other marks or used in a misleading manner. Your use of these logos is subject to your compliance with these Guidelines.

Logos For Use By Partners

If you have a current agreement with Doximity, you may use logos in accordance with the terms of your agreement and these Guidelines. You can download Doximity logos here.

Use Requirements and Terms

All permitted uses of the Doximity Marks must conform to the following guidelines:

No Modification. The Doximity Marks must be used as provided by Doximity with no modifications. Don’t remove, distort or alter any element of the Marks, including changing any colors. Do not shorten, abbreviate, or create acronyms out of the Marks.

No Confusingly Similar Marks. Don’t use the Marks in a manner that might create potential confusion as to the owner of the Doximity Marks or imply that Doximity is the source of your products or services.

No Incorporation. Don’t incorporate the Doximity Marks into your own product name, service names, trademarks, logos, company names, domain names, website title, publication title, application icon, favicon, or the like. Don’t incorporate or use the “d” logo as part of a word.

No Generic Use. Don’t use the Doximity Marks in a way that suggests a common, descriptive, or generic meaning.

No Plural or Possessive Use. Never use the Doximity Marks in the plural or possessive form.

Domain Names. Don’t register the Doximity Marks as domain names or as any part of a domain name.

Trade Dress. Don’t copy or imitate Doximity’s website design, typefaces, distinctive color, graphics designs or imagery.

Endorsement. Don’t display the Doximity Marks in any manner that might imply a relationship or affiliation with, sponsorship, or endorsement by Doximity, or that can be reasonably interpreted to suggest that any content has been authorized by or represents the views or opinions of Doximity or Doximity personnel.

Prominence. Don’t display the Doximity Marks as the primary or most prominent feature on your web page or in any non-Doximity materials.

Disparagement. Do not use the Doximity Marks in a manner that would disparage Doximity, Inc. or its products or services.

Violation of Law. Don’t display the Doximity Marks on any web site that contains or displays adult content, promotes gambling, involves the sale of tobacco or alcohol to persons under twenty-one years of age, or otherwise violates any law or regulation.

Objectionable Use. Don’t display the Doximity Marks in a manner that is in Doximity’s sole opinion misleading, unfair, defamatory, infringing, libelous, disparaging, obscene or otherwise objectionable to Doximity.

Attribution. The Doximity Marks must be accompanied by the appropriate ® or ™ symbol. If you use the Marks outside the United States, please see Use Outside the US below.

Use Outside the US. Trademark rights vary from country to country. Some countries have penalties for improper use of the registration symbol ®. If using the Marks on sites based outside the United States, use the ™ symbol unless otherwise noted in these Guidelines.

Termination. Doximity may ask you to stop using the Marks at any time. You agree to stop using the Marks within a reasonable period of Doximity’s request, but in no situation, more than seven (7) days after Doximity’s request.

Reservation of Rights. Doximity is the owner of all rights in the Marks and reserves all rights save the limited license granted here. Your use of the Marks pursuant to this license shall not be construed as limiting any of Doximity’s rights in the Marks.


Additional Information

Doximity requires that you conform to these Guidelines in your use of any Brand Features. We may modify these Guidelines at any time and your continued use of the Brand Features will constitute your consent to such modifications. Doximity has complete discretion in determining if your use violates any of the Guidelines.

If you would like to make use of the Brand Features in a manner not within the following Guidelines, you must seek our prior written permission by submitting the Request for Permission Form.

For assistance in understanding these Guidelines, please contact us at

Doximity API Platform Guidelines

We designed the Doximity API platform to allow users to use their Doximity accounts in your applications. By following these guidelines, we can ensure that our common users have the best possible experience with your product. Doximity reserves the right to limit or block your access to the site and the APIs should your application be found to violate these guidelines.

The Big Picture

Here is a summary of the major themes we cover in our rules below. Please refer to our API Terms of Use for details.

  1. Doximity is a professional network. We ask that you do not implement features or business practices that could be harmful to the professional reputations or relationships of Doximity members.
  2. Don’t store Doximity data: The exceptions here are a) storing User ID for subsequent API calls, and b) storing user profile data when the profile owner has given explicit permission through a Doximity-provided interface for obtaining user consent
  3. Don’t share your Access Codes/API Keys with anyone.
  4. Don’t expose Doximity user account/network data with other users: Doximity users that give your application access to their Doximity account should only be able to see data from their own Doximity network.
  5. Don’t use the APIs in conjunction with, or combine any Doximity API content with data scraped by you or other third parties from Doximity. While we are excited that our develop resources are used to create innovative applications, Doximity APIs should be the sole source of Doximity user data.
  6. Show the agreement screen in its own window. The user agreement page where the user grants access to their Doximity account must be presented in a browser window where the URL is clearly visible - it cannot be iframed into the current page. We want it to be clear to the user that the URL is
  7. Don’t provide API access to your customres: The use of the Doximity APIs cannot be provided as a feature of your product - we require a direct relationship with any application making API calls.

Dox Etiquette

Here are some rules to keep the use of the APIs running smoothly and efficiently.

  1. If you have a lot of calls to make, submit them over a period of time. Spacing out your API calls to the extent possible - without hurting user experience - will optimize API performance for you and all other developers.
  2. Ask for only the minimum data fields that your application needs to function properly; asking for only necessary fields will result in faster performance times - for you, and for us!

Data Storage

Doximity users own their data and must control it. We ask that you not store the data we return in an API call to respect our users. Here are the details:

  1. You cannot store any data your receive from Doximity APIs with the exception of User IDs you receive.
  2. The exception: you may store the profile of a user if you specifically ask the profile owner to store his/her profile and make it clear that you intend to store it. In this situation, you can only store the data of the person that has granted access.
  3. Doximity data is not transferable.
  4. Content obtained through the Login with Doximity Plugin should not be used to create profiles on your own or a third party site/service/application.

Advertising & Promotions

  1. Doximity data should not be used to determine whether/which ads and promotions should be displayed.
  2. Doximity data should not be used to determine ad/promotion content.
  3. Doximity data cannot be used within an ad.
  4. Ads should not be inserted into displayed Doximity content (profiles, etc.). We want it to be clear to users whether content is coming from Doximity or from your application.

Revenue & Charging

This one is simple: you cannot charge our users for access to Doximity or data imported from Doximity using the API

Attributing content to Doximity

Following these guidelines will help us make sure that our users know where content is coming from.

  1. Use the “d” icon or the Doximity name in text to attribute information to Doximity.
  2. When you display a profile, groups, or any other Doximity information, in whole or part, it must be made clear that the information came from Doximity.
  3. When you display Doximity content, we ask that you include a link to the same content on Doximity.

Press and Public Mentions

Doximity does not systematically review and approve the use of our APIs. As such, we ask that you not make statements that indicate that there is a relationship between our companies or products if this is factually incorrect.

  1. Do not indicate that there is any business relationship or partnership of any kind between your company and Doximity.
  2. Do not indicate that your integration is endorsed by Doximity in any way.
  3. Do not include the Doximity name or brand on your partner pages.
  4. Do not indicate that using our APIs gives you visibility or access to the entire Doximity user base or portions of it beyond the user’s own network. No single user has complete visibility to all Doximity data through the APIs - we don’t want there to be any confusion on this.
  5. Do not indicate that your integration allows any user to circumvent Doximity website requirements for visibility or access - our API Terms of Use does not allow for this capability to be built in.

Brand Mark Use

Here is how to use Doximity Brand Marks. Doximity Marks includes any element of the Doximity brand, including the Doximity name, logo, and “d” icon. Other versions of the Doximity brand representation should not be used.

All permitted uses of the Doximity Marks must conform to these guidelines:

  1. Use the iconic “d” graphic to indicate Doximity features where a short, graphical element is required. Do not use the full Doximity logo here.
  2. Use the name “Doximity” in text where you want to refer to the full name. Do not use the Doximity logo.

Questions about our API?