The integration screen is finished and a trial with invented data succeeds, but the company's account has not received permission to perform the operation with the provider. Is the project complete or stalled? That depends on the agreement made beforehand. Working local code does not establish production integration availability.
When buying a third-party integration, separate development progress from approval progress. The developer can prepare part of the solution, while some decisions belong to the account owner, service provider or administrator of the connected system. A dependency register makes their effect on work and timing visible before launch approaches.
Example: creating a shipment from a store order
In a fictional example, a sporting goods store wants to send order information to a shipping company. The developer can prepare field mapping and monitoring screens while the store completes its commercial account arrangements and the provider enables a particular permission. No provider name, terms or guaranteed activation is assumed.
There are three different kinds of evidence: an internal simulation showing how code handles an expected response, a trial in an available provider test environment and an authorized production trial on the intended account. “Tested” should identify which evidence exists and what remains unproven.
A seven-field dependency register
- Required operation: shipment creation, for example, rather than only an API or company name.
- External prerequisite: permission, account, review, environment or usage limit requiring confirmation.
- Action owner: an authorized customer or counterpart representative, with a project follow-up owner.
- Completion evidence: suitable official confirmation or a permitted test establishing the operation in its specified environment.
- Target date: a follow-up date and planning assumption, distinguished from a binding date controlled by another party.
- Affected work: what stops and what can be built or tested without that input.
- Delay decision: defer a workflow, approve a manual alternative or seek approval for a plan change.
Review the register during progress meetings and update states using evidence rather than expectation. “Submitted” differs from “under review” and “access granted”. If a temporary simulation is used, state when it will be replaced and how the scenario will be repeated against the actual service.
Access has a scope, not just a key
Shopify documentation explains that scopes determine which data an application can read and write. Connectivity therefore does not imply permission for every operation. Request confirmation for the actual case, and do not request write permissions when the agreed scope only needs reading.
Google guidance explains that applications requesting certain sensitive or restricted user-data scopes may need verification, with case-dependent exceptions. This illustrates a possible external dependency, not a universal integration requirement or an approval duration applicable to your project. The supplier should review the actual interface's rules during implementation.
Ask what the test environment does not establish
Accounts, data, limits and settings may differ between testing and production. Request a list of material differences and checks required before operation. In the shipping example, a fictional shipment number does not establish that your account can issue a real shipment under its commercial agreement.
Identify each piece of evidence's environment, interface version and check date. If permission changes or access expires later, who detects it and follows up renewal? This separates connection maintenance from initial construction and avoids operations depending on an account belonging to someone who left the organization.
Make delay consequences an explicit decision
Data mapping, completed components and their tests might be delivered while production operation remains pending. Specify acceptance criteria and conditional acceptance boundaries for each output without describing the entire workflow as live. For an approved temporary manual path, assign ownership and prevent duplicate execution when integration takes over.
Request rescheduling or retesting costs if approval arrives after a long interruption. Do not turn a guessed external duration into the developer's commitment, or excuse the developer from work it can complete within scope. The register clarifies each party's responsibility and impact; it does not replace project management.
Consult the integration brief and data map for functions and failure and retry acceptance tests for behavior. When requesting system integration from Nextwave, attach the register so timing rests on inputs that can be followed up.
Access and review sources
Shopify scope documentation and Google sensitive scope verification guidance were opened on 3 November 2026. They establish examples of access and review boundaries. The register and example are buying guidance; no applications were submitted, accounts changed or approvals guaranteed.
