--- title: "Developers" description: "Use Ordering.co’s public API reference and developer guides to frame an integration before you agree its implementation scope." canonical: https://www.ordering.co/developers/ --- # Start an Ordering.co integration from the public contract. Ordering.co documentation provides developer guides and a public API reference for requests, authentication, parameters, schemas, and responses. The reference is read-only: no approved remote sandbox is currently configured for interactive testing. [Open API reference](https://docs.ordering.co/api-reference/)[Read developer guides](https://docs.ordering.co/docs/developers/) - Public API reference - Developer guides - Read-only testing boundary API reference ## Review the public interface before you design against it. The public API reference is the source for operations, parameters, schemas, and responses. Use it to turn an idea into a technical question that an implementation team can evaluate precisely. - ### Operations The available actions are organized as reference operations rather than implied by a sales page. - ### Parameters Inspect the inputs a request describes before mapping your own data to it. - ### Schemas Use the documented object shapes to clarify what an implementation needs to exchange. - ### Responses Review the documented results and error shapes before you plan an integration flow. [Open API reference](https://docs.ordering.co/api-reference/) Developer guides ## Use the guides to connect the interface to the product work. The developer documentation is written for teams integrating with Ordering.co products or contributing safely to product repositories. It points back to the canonical API reference for requests, schemas, and authentication. - ### Integration purpose State the product workflow your team is trying to support before selecting technical work. - ### Authentication Use the documented authentication guidance instead of placing credentials into an unreviewed prototype. - ### Cross-product handoffs Map where an integration touches another product or operating team so responsibility stays clear. - ### Safe contribution Follow the documentation path when a team is contributing to product repositories. [Read developer guides](https://docs.ordering.co/docs/developers/) Implementation brief ## Design from the documented contract, not a package assumption. A useful brief names the workflow, the documented operations under review, the data owner, and the acceptance check. That gives technical and operating teams one shared starting point. - ### Workflow Describe the customer or operator outcome the integration must support. - ### Objects List the documented operations and schemas your team needs to inspect. - ### Ownership Name who owns source data, credentials, monitoring, and changes. - ### Acceptance Define the demonstrated result that will show the chosen scope works. [Review API reference](https://docs.ordering.co/api-reference/) Handoffs ## Treat each handoff as an operating responsibility. Integration guides explain routes and cross-product handoffs. Before implementation, decide which team receives a change, how it checks the outcome, and what happens when an expected handoff needs attention. - ### Trigger What documented change starts the handoff? - ### Receiver Which system and team own the next step? - ### Verification How will the receiving team confirm the expected outcome? - ### Recovery Who investigates when the expected result is missing or inconsistent? [Read developer guides](https://docs.ordering.co/docs/developers/) Safe testing ## Review first; do not treat the public reference as a live environment. Ordering.co’s testing guidance states that the public API Reference is read-only and that no approved remote sandbox is configured for interactive testing. Plan any test environment and credentials through the appropriate implementation process. - ### Reference access Use the public interface to inspect operations and documentation safely. - ### Interactive testing Do not assume a browser-based request can run against a remote sandbox. - ### Credentials Keep keys, tokens, and customer identifiers out of the public reference and planning artifacts. - ### Test plan Agree the environment, data, and acceptance check before testing a live integration. [Read testing requirements](https://docs.ordering.co/docs/developers/api-reference-sandbox-testing/) Product guides ## Keep the documented product context close to the build. The Ordering.co documentation home groups product guides with the developer area. Use the relevant guide alongside the API reference so technical work remains connected to the product workflow it supports. - ### Product guide Read the guide for the product surface affected by the integration. - ### API reference Use the canonical operations, parameters, schemas, and responses as the interface source. - ### Operating owner Confirm who will use and maintain the resulting workflow. - ### Release check Record the observable outcome the team will validate before relying on the integration. [Open product guides](https://docs.ordering.co/) Choose the next step ## Match the next conversation to the decision you actually need to make. The public reference answers interface questions. Product, commercial, and operating scope still need to be agreed for the specific implementation. - [Inspect the API referenceReview documented operations, parameters, schemas, and responses before proposing a technical path.](https://docs.ordering.co/api-reference/) - [Read the developer guidesUse the guides to connect interface decisions to product integration and safe contribution practices.](https://docs.ordering.co/docs/developers/) - [Explore Automation integrationsReview the specific webhook, API, authentication, workflow, and location references, then confirm which path applies to your project.](https://www.ordering.co/integrations/automation/) - [Define the product scopeFor a branded or specialized build, identify the surfaces, responsibilities, and acceptance checks that need a scoped decision.](https://www.ordering.co/developers/white-label/) - [Discuss the implementationBring the workflow, technical questions, data ownership, and test plan to the team responsible for the project.](https://www.ordering.co/contact/) One documented starting point ## Frame the work around a public interface and clear owners. An integration brief connects the workflow your team is building to the documented interface it needs to review. The technical reference and the operating acceptance check should stay together throughout the project. What your team brings - Your workflow - Your data owner - Your release plan ![Ordering.co](https://www.ordering.co/assets/logos/ordering-lockup-color-on-white.svg)![Ordering.co](https://www.ordering.co/assets/logos/ordering-lockup-color-reversed.svg)**Ordering.co API reference**Operations · Parameters · Schemas · Responses What the project must resolve - Authentication - Implementation scope - Acceptance check ## Start with the reference, then make the scope concrete. Review the public interface first. When you are ready to plan the implementation, bring the workflow, data responsibilities, and acceptance criteria rather than an assumed capability list. [Read developer guides](https://docs.ordering.co/docs/developers/)[Talk to Ordering.co](https://www.ordering.co/contact/)