When adding a Customer API post API returns success while GET

[Abhishek-Singh28]

We are attempting to automate the Provisioning of the Wholesale customers and then add location and users to the organisation. The volume in future can increase for users upto 1000 - 5000 per customer, we want to ensure the calls are successful and can rely on the APIs. Please provide any insight for the following query

1. create customer sometimes returns 201 as response but GET customer details displays status as provisioning and stalls the further APIs due to partial provisioning - we would like to understand when this could happen as it is rare but happens during bulk provisioning

Create customer: /wholesale/customers [POST]

The api also has the required package details in the payload

Response: 201 ok

No body

Get customer: wholesale/customers/{customerId} [GET] 

Response:

200 ok

[  {
    "externalId": "customer_number",
    "name": "NAME",
    "id": "orgid",
    "fullAddress": "address details,
    "orgId": null,
    "status": "Provisioning"
  }]

The GET response return status as 'Provisioning' then later from the front end , the Customer page is sort of disable state, not even allowing to add the packages.

This does not happen all the time and but we have observed in 1 out of 10 customer create. 

2. Question - For wholesale customer - we are currently only using POST /wholesale/customers with packages for customer create and then for users POST vi/people and assigns the required licenses during person create 

What would be the use of the API /wholesale/subscribers ]POST] - if not used do you see any impact on provisioning or billing. We are already assigning the required packages during the customer create and then also adding the licenses during person create.

The reports on Subscriber as well does not show any impact.

From the Cisco UI we only have create customer and user, where from the UI as well we can find the Subscriber add functonality. 

Thanks 

Regards

[Abhishek-Singh28]

@Janos Benyovszki - may i request you to kindly respond to the other question as well. My apologies forgot to tag you in the question, hence tagging now

[Abhishek-Singh28]

thanks Janos

Also if you can look into the second question please. 

In Control Hub, user creation allows packages to be assigned, and those packages are already defined under the customer.

From an API perspective, we see two different APIs being used: /wholesale/subscribers and /v1/people. My understanding is that the Wholesale Subscriber API is intended for partner/service-provider provisioning in the Webex Wholesale model, where it creates a billable service subscriber, whereas the People API creates a registered user/person in Webex.

Could you please clarify how Cisco treats these two types of records differently once created? For example:

1. If a user is created through /wholesale/subscribers versus /v1/people with assigned packages, how are they distinguished within the Cisco platform?
2. Are there any specific reports that identify subscribers separately from users/people?
3. From a billing and reconciliation perspective, given that reports are a key input for partner billing, would using one API instead of the other have any impact?

We want to ensure that the correct API is used so there is no unintended impact on reporting, billing, or reconciliation.

[Janos Benyovszki]

@Abhishek-Singh28 In Webex, the /wholesale/subscribers API and /v1/people API serve different roles: the former is used in the Wholesale model to create billable subscribers tied to packages and partner provisioning systems, while the latter simply creates a user identity (person) in Webex. Although both may result in a usable end user, only subscribers created via /wholesale/subscribers are reliably reflected in wholesale billing, reporting, and reconciliation, since they are tracked in Cisco’s partner billing systems. Using /v1/people alone may create valid users but can lead to gaps or inconsistencies in billing reports, so for wholesale scenarios, the subscriber API is the recommended approach.

[Janos Benyovszki · Accepted solution]

@Abhishek-Singh28 A 201 from POST /wholesale/customers only means the create was accepted; provisioning the org (packages, backend hooks) usually finishes asynchronously, so GET /wholesale/customers/{id} can correctly show Provisioning right after success—that’s expected, not a contradiction. Under bulk or parallel creates, that window gets longer and downstream calls may fail if they run before the org is fully ready. One approach might be to treat customer create as async—poll GET with backoff until status reaches the active/ready state your flow needs, cap concurrency on creates, retry transient 5xx/timeouts, and only chain locations/users after the customer is ready; if status stays Provisioning past a reasonable SLA, capture API request + response + tracking IDs and open a Developer Support case.