Alliance-aiab

This API serves dual purposes: order creation and enrichment. Users employ it to generate new orders and enhance existing ones. The order enrichment process encompasses various facets of fulfillment. Initially, installation enrichment entails gathering additional information about installation contacts, including customerRequestedStartDate, customerRequestedDueDate, and premise notes. Subsequently, shipping address enrichment enhances details such as email IDs, addresses, and relevant shipping notes. Thirdly, product billing configuration enrichment involves quote IDs, ordered items, suborders, and invoice numbers. Lastly, the CDG (Customer Defined Group) enrichment enables SP to consolidate orders. These enrichments collectively facilitate a smoother order fulfillment process, addressing aspects from installation logistics to billing considerations and beyond.

Security

This RESTful service uses a client id enforcement policy as the authentication mechanism. Please work with the Client On-Boarding Team if you do not have the necessary credentials.

Endpoints and Headers

Order POST API

Installation PUT API

Shipping POST API

Billing POST API

Order Summary POST API

If you are a Connector—meaning you develop on behalf of multiple Solution Provider accounts to retrieve information for them, you will use the same URL and ensure that you pass the unique client header per Solution Provider.

API Headers

The following are the fields in the request headers of Order Enrichment API.

FAQ (Order Enrichment, Service Appointment, and Submit)

1) Why does the Installation / Order Enrichment step fail even though my credentials are correct?

In the test/sandbox environment, failures at the installation/order-enrichment step are often caused by site address test data not being mocked for all addresses in a downstream system. This can look like an authorization or customer restriction issue, but it’s actually a test-data limitation.

Workaround (Sandbox): use a known-good test address (example below).
Note: This limitation is not present in production.

Known-good sandbox address:

jsonCopy Code

{
"street": "2270 LAKESIDE BLVD",
"city": "RICHARDSON",
"state": "TX",
"postalCode": "75082"
}

2) Which address fields should I use: zip, postalCode, or zipcode?

Use the field names expected by the specific endpoint schema.

• Some request bodies expect zip (not zipcode)
• Some steps use postalCode
• Do not use zipcode unless the schema explicitly documents it (older examples may be outdated)

Example using zip:

{
"street": "3400 W Plano",
"city": "Plano",
"state": "TX",
"zip": "95350-1232"
}

3) I get “Previous Step (Service Appointment) is not complete.” What does that mean?

This error indicates that the Service Appointment steps are required before order submission, even if you have already completed Installation/Order Enrichment.

Before submitting, make sure you have completed both:

1. Get Service Appointment Dates (retrieve available appointment windows)
2. Book Service Appointment Date/Time (select and reserve a specific slot)

If either step is skipped or fails, submit will return: “Previous Step (Service Appointment) is not complete.”

4) The endpoint /api/v1/submit does not exist. What should I call to submit the order?

Some documentation references a submit endpoint that may be deprecated or removed in the environment you are using.

If /api/v1/submit returns 404, use the current order submission endpoint listed in the Ordering API endpoint reference (for example, /api/v1/order, depending on your environment/version).

5) Service Appointment booking fails—what should I try first?

If Service Appointment calls fail in sandbox, first validate test data and availability, not credentials.

Recommended troubleshooting:

• Try shifting the appointment window by 1–2 days
• Try a different available slot returned by the “Get SA Dates” response
• If issues persist, retry using the known-good sandbox address (see FAQ #1)

Example slot format:

{
"startDate": "2025-12-08 08:00:00.000",
"endDate": "2025-12-08 16:00:00.000"
}

6) How can I tell whether this is an authorization issue or a sandbox test-data issue?

Use these quick signals:

Likely authorization (clientID/customerID) issue

• Clear 401/403 responses
• Errors explicitly stating unauthorized/forbidden/invalid client

Likely sandbox test-data / downstream limitation

• Same call works when changing only the address
• Errors vary based on date/slot availability
• Installation/Service Appointment fails for some addresses but succeeds for others

7) Are these limitations present in production?

No. The mocked address limitation described above applies to the test/sandbox environment and is not present in production.