Alliance-aiab

At this stage, it allows SPs to gather essential data related to a targeted end customer based on the address and fuzzy name provided. This includes crucial information such as Alliance status (e.g., AT&T only status which implies that AT&T can only do business with the end-customer) and customer specifics like sub-account ID.

API 1 — POST Customer Account Lookup

This API returns up to five possible end-customer accounts based on a fuzzy (wildcard) account name search and (optionally) an address to refine results. It is the initial step in the Ordering API flow and helps identify key attributes such as allianceStatus and the subAccountId used in downstream APIs.

Endpoint

POST /api/v1/customerAccountLookup

Authentication / Headers (Summary)

This service uses client id enforcement. Ensure your request includes required headers such as:

• content-type: application/json
• client_id
• client_secret
• x-trace-id (required)

Request Body Parameters

• spId (required): Solution Provider ID.
• accountName (required): Fuzzy/wildcard account name search. Minimum 3 characters required.
• address (required): Address object used to refine results.
  The address object must be included and contains:

Note: While street supports fuzzy matching and may be blank, city/state/zipCode require exact matches.

Address array:

• street (required in structure; value may be blank): Fuzzy/optional value, but the field must exist in the payload.
• city (required): Exact match.
• state (required): Exact match (e.g., TX).
• zipCode (required): Exact match.

Example Request

{

"spId": "10006",

"accountName": "ABC",

"address": {

"street": "",

"city": "PLANO",

"state": "TX",

"zipCode": "75075"

}

}

Response

The API returns a list of matching accounts (up to 5). Common fields include:

• accountName – End customer name
• accountId – End customer ID
• subAccountId – Unique identifier used for subsequent APIs
• allianceStatus – Possible values: AT&T ONLY, OPPORTUNITY
• accountStatus – ACTIVE, INACTIVE, PROSPECT
• exception – Y / N
• salesSegment, acid, contractStatus, partnerId, parentPartnerAccId (as applicable)
• accountAddress – address details

Result Limits / Matching Rules

• Maximum of 5 results are returned.
• If more than 5 end customers match the inputs, the response will indicate the search must be refined (i.e., narrow the search with a more specific name and/or address).
• accountName must be at least 3 characters.

How to Use the Results

1. Submit your query with spId, accountName (≥ 3 characters), and address fields.
2. Review the returned accounts and focus on:
3. Check allianceStatus.
4. • If AT&T ONLY: check exception
   • If exception = Y, you may proceed
   • If exception = N, the customer is ineligible
   • If OPPORTUNITY: you may proceed
5. Use subAccountId as the unique identifier for future API steps.

Notes

• accountName is a fuzzy search; city/state/zipCode require exact matches.
• If you get no usable results, refine the search (more specific accountName, add/adjust address details).
• Result limiting helps protect account information.

API 2 — GET Solution Provider Contact Lookup

Endpoint

GET /api/v1/solutionProviderContactLookup

Description

Fetches name/address details, LOA status, contract details, and partner details associated with the specified subAccountId.

Request Parameters

The source document indicates this operation is “associated with the specified subAccountId”, but the request formatting is unclear in the text you provided.

Implementations typically use one of these patterns (confirm which your gateway expects):

• Query param pattern: GET /api/v1/solutionProviderContactLookup?subAccountId={subAccountId}
• Path param pattern: GET /api/v1/solutionProviderContactLookup/{subAccountId}

The documentation also mentions: spId (optional) as a query parameter for this scenario.

Example (Query Param style)

GET /api/v1/solutionProviderContactLookup?subAccountId=12345&spId=10006

Response

Returns an array of contacts. Example structure:

[

{

"type": "Partner Contact",

"firstName": "test",

"middleName": null,

"lastName": "test",

"title": "MR",

"email": "test@gmail.com",

"telephone": "(111)222-1111",

"country": "US",

"streetAddress": "1st test,Mission St",

"city": "San Francisco",

"state": "CA",

"zipCode": "91000"

}

]

Notes

• This GET is typically used after POST returns the right customer and you have the correct subAccountId.
• Unlike the POST response guidance, you may still see loaStatus surfaced in related data—your earlier rule (“ignore loaStatus”) applies to your flow unless your process changes