Zernio
Zernio
API Reference

Branded Calling

List pre-approved call reasonsGETList registered businessesGETList caller identitiesGETList the numbers on a caller identityGETRegister a business for Branded CallingPOSTCreate a caller identityPOSTGet a registered businessGETGet a caller identityGETEdit or resubmit a caller identityPATCHDelete a registered businessDELETEDelete a caller identityDELETEAttach numbers to a verified identityPOSTConfirm the authorizer's codePOSTDetach numbers from an identityDELETEDry-run a caller identity before creating itPOSTResend the authorizer's codePOSTCreate a caller identity share linkPOST
Dashboard
llms.txtOpenAPI
OverviewPlatformsAPI ReferenceResources
Branded Calling

Detach numbers from an identity

Deregisters the numbers at the carrier and frees them for another identity. Up to 100 per call.


DELETE
/v1/branded-calling/identities/{id}/numbers

Authorization

bearerAuth
AuthorizationBearer <token>

API key authentication: send your Zernio API key in the Authorization header, prefixed with Bearer.

In: header

Path Parameters

id*string

Request Body

application/json

TypeScript Definitions

Use the request body type in TypeScript.

Response Body

application/json

application/json

application/json

import Zernio from '@zernio/node';const zernio = new Zernio({ apiKey: process.env.ZERNIO_API_KEY });const { data } = await zernio.brandedcalling.detachBrandedCallingNumbers({  path: {    id: 'abc123',  },  body: {    phoneNumbers: [      'string',    ],  },});console.log(data);
{  "removed": [    "string"  ]}
Was this page helpful?

Confirm the authorizer's code

The last customer step. On success the stored references are filed and the identity is submitted to carrier vetting in the same call (`in_review`). If a later step fails the identity stays `pending_email_verification` with the email already verified; calling again resumes from that step.

Dry-run a caller identity before creating it

Validates the exact body `POST /v1/branded-calling/identities` takes and runs the same deterministic lints the review runs on it without creating anything, with the same codes and fields the queued identity's findings carry. A `block` finding is what the review would bounce (two references sharing a phone, a reference inside the business, an invalid timezone); a `warn` finding slows vetting (a display name that does not read as the business, a call reason outside the carrier catalogue, a public-mailbox authorizer, a logo that does not answer). `ok` is true when there is no `block`.

phoneNumbers*array<string>

E.164 numbers currently on this identity.

Items1 <= items <= 100