Official: IdentityNow Postman Workspace

IdentityNow Postman Workspace

Here you will find the official Postman Workspace for IdentityNow APIs. If you have any questions, comments, suggestions, or issues with this workspace or any collections within, let us know here.

Getting Started

You will forever find the IdentityNow workspace here: IdentityNow Postman workspace

You can also click these buttons if you just want a single collection :arrow_down:

API Postman Collection
V3 API Run in Postman
Beta API Run in Postman
V2 API Run in Postman
cc/private API Run in Postman
SaaS Connectivity Run in Postman

When you navigate this link, you’ll see our workspace, and you’ll find the collections of APIs on the left-hand side. Read the following guide to learn how to use them:

Fork the Collection

  1. Hover over the collection you’d like to fork, click the ellipse on right-hand side, and click ‘Create a fork’.

  1. Choose a label for your forked collection, choose the workspace that you’d like to fork it into (usually “My Workspace,” unless you know what you’re doing), and ensure that ‘Watch original collection’ is checked.

  1. Click the ‘Fork Collection’ button.

Getting Collection Updates

This is the big one, right? What about when the APIs get updated? Thankfully, Postman has a feature built-in for this, and it ties back to your ensuring that the ‘Watch original collection’ option is checked.

All you have to do now to check for updates is this - in your own personal workspace where you forked the collection, do the following:

  1. Hover over the collection, click the ellipse on the right-hand side, and click ‘Pull changes.’

  1. If there are no new changes, then you are up to date. If there are new changes, it will look like the following image. Just click the Pull Changes button, and that’s it!

Collection Features

In addition to managing the collections for you, we’ll continue to add features as they’re requested and we can get to them. Got a collection/workspace level request? Let us know here!

To boot, we’ve added a collection feature to V3 APIs originally posted by @Rich_Miller on automating JWT creation and improved by @atarodia to automatically retrieve the token when it expires. Thanks to Richard and Animesh for their contributions!

4 Likes

Hey @jordan_violet,

I just wanted to provide some initial observations,

The below endpoints seem to be missing from their respective collections.
I’m happy to help gather details on them if needed.

CC:

/cc/api/user/get
/cc/api/system/getStatus

V2:

/v2/dashboard

I’ll keep an eye out for more like this as I use the collection :slight_smile:

@LukeHagar, please! If you can send me all of the call details, or even a sample collection with those calls in them, I can get them added to the SailPoint collections.

Regarding the “BETA” API’s

  • Will a collection be added for these also?
  • Any plans for communications regarding API’s moving from “BETA” to “V3”?
1 Like

Great question! I can’t believe I missed the Beta APIs! They’re added now :slight_smile:

As for communication APIs moving from Beta to V3, give us some time and we’ll have a process for that soon!

One piece of feedback - it looks like the hierarchy for each endpoint has been removed in most cases.

I.e. Under v3/sources folder, the last API spec I imported had generic (not single) calls directly within, then subfolders for calls which required an ID. This made is really easy to determine which were the base calls for a given endpoint and which were sub calls of the end point. This was pretty handy in sources as it had a few levels of subfolders as you started looking at the schema/policy management sub-endpoints.

Can we re-instate the folder structure?

1 Like

Hey @jordan_violet,

Here is what I have so far on those Endpoints (Not Complete):

GET /v2/dashboard

Response Shape:

export type dashboard = {
  access: any[];
  accessCount: number;
  accessProfileCount: number;
  accountCount: number;
  accounts: any[];
  appCount: number;
  attributes: any;
  created: string;
  displayName: string;
  email: string;
  entitlementCount: number;
  firstName: string;
  id: string;
  identityProfile: any;
  inactive: boolean;
  isManager: boolean;
  lastName: string;
  modified: string;
  name: string;
  owns: any;
  ownsCount: number;
  protected: boolean;
  roleCount: number;
  source: any;
  status: string;
  synced: string;
  tags: any[];
  tagsCount: number;
  visibleSegmentCount: number;
};



GET /cc/api/user/get

Response Shape:

export type userResponse = {
  alias: string;
  altAuthVia: string;
  altAuthViaIntegrationData: null;
  attributes: { lastLoginTimestamp: number; uid: string; firstname: string };
  auth: { service: string; encryption: string };
  bxInstallPrompted: boolean;
  disablePasswordReset: boolean;
  displayName: string;
  email: string;
  employeeNumber: null;
  enabled: true;
  encryptionCheck: null;
  encryptionKey: null;
  externalId: string;
  feature: string[];
  featureFlags: any;
  federatedLogin: boolean;
  id: string;
  kbaAnswers: number;
  loginUrl: string;
  meta: any;
  name: string;
  onNetwork: boolean;
  onTrustedGeo: true;
  org: {
    actionButtonColor: string;
    activeLinkColor: string;
    adminStrongAuthRequired: boolean;
    authErrorText: null;
    brandName: string;
    countryCodes: null;
    emailFromAddress: string;
    emailTestAddress: string;
    emailTestMode: boolean;
    enableAutomaticPasswordReplay: boolean;
    enableAutomationGeneration: boolean;
    enableExternalPasswordChange: boolean;
    enablePasswordReplay: boolean;
    integrations: any;
    kbaReqAnswers: number;
    kbaReqForAuthn: number;
    lockoutAttemptThreshold: number;
    lockoutTimeMinutes: number;
    logo: null;
    maxClusterDebugHours: string;
    maxRegisteredUsers: number;
    mode: string;
    name: string;
    narrowLogoUrl: null;
    navigationColor: string;
    netmasks: null;
    notifyAuthenticationSettingChange: boolean;
    numQuestions: number;
    orgType: string;
    passwordReplayState: string;
    pod: string;
    productName: string;
    pwdResetDuo: boolean;
    pwdResetEmail: boolean;
    pwdResetKba: boolean;
    pwdResetPersonalEmail: boolean;
    pwdResetPersonalPhone: boolean;
    pwdResetPhoneMask: boolean;
    scriptName: string;
    standardLogoUrl: null;
    status: string;
    strongAuthKba: boolean;
    strongAuthPersonalEmail: boolean;
    strongAuthPersonalPhone: boolean;
    systemNotificationConfig: string;
    usageCertRequired: boolean;
    usernameEmptyText: null;
    usernameLabel: null;
    whiteList: boolean;
  };
  orgEncryptionKey: string;
  orgEncryptionKeyId: string;
  passwordResetSinceLastLogin: boolean;
  pending: boolean;
  personalEmail: null;
  phone: null;
  ptaSourceId: null;
  riskScore: 0;
  role: string[];
  status: string;
  stepUpAuth: boolean;
  supportsPasswordPush: boolean;
  uid: string;
  usageCertAttested: null;
  userFlags: any;
  uuid: string;
};

There ARE some incorrect types here, mainly the null ones, a couple of any types as well, I don’t have perfect examples to pull from

Do you have an old collection or screenshot you could DM me so I could see this visually?

@LukeHagar do you know if those would go in their own folders, ‘Dashboard’ and ‘Users’, respectively, or if they’d fall under an existing folder/tag?

Ah, interesting, that is a collection by OpenAPI paths instead of OpenAPI tags. It would be possible for us to do that, but I know most people are used to folders by tags.

I’m going to see if we can generate multiple collections, so we can do them by both path and tag.

1 Like

I just noticed a spelling difference for the “cc” collection where it’s “Identity Now cc (private) APIs” vs. “IdentityNow …”

Good catch @edmarks–fixed :slight_smile:

1 Like

@christina_gagnon brought to my attention that some of the requests throughout the V3 and Beta collections had Oauth 2.0 instead of inherit from parent. I fixed that, and now all requests are set to inherit from parent.

You’ll get these changes whenever you pull the latest changes :slight_smile:

Hey @jordan_violet,

In V2 API Collection under Access Profiles and Apps, some of the End Point has {{name}} which makes it unusable for Vanity URLs. Can you please change it to {{api-url}}.

image

1 Like

@atarodia thanks for looking out. I actually changed it to {{baseUrl}} and inserted {{tenant}} and {{baseUrl}} as collection variables, just like V3 and Beta collections have, that way there is some consistency.

Hey @jordan_violet - this is fantastic!! Have transitioned over this week!

One additional private API that seems to be missing is an API list all of the cloud rules from the tenant:

CC:
GET /cc/api/rule/list

I use this to verify the rules are imported into each tenant (once unescaped)

Thanks
Chris

1 Like

@whoiscjay I’m glad to see you’re using the official collection!

Thanks for helping us improve the cc API collection. The endpoint you mentioned has now been added to the collection. If you have any information on the request body, headers, etc. I’ll add them as well.

I noticed on the V3 and Beta collections that the {{tenant}} value is blank or has “sailpoint”, respectively. Would it be possible to change the default value of that field to “{{name}}”?

1 Like