Search
Advanced Certificate on pass

Partner Technical / ISV Integration

Build on AWRA — connect systems through the APIs and sync hub, and ship an integration you can list in the marketplace.

4 lessons 40 min 5-question assessment 80% to pass

What you’ll learn

  • Explain how AWRA exposes data and events to integrators
  • Use the sync hub to keep systems in step
  • Design a reliable, well-scoped integration
  • Prepare an integration for the marketplace

Course content

4 lessons · 40 min of reading
01
Lesson 1 of 4 Reading 9 min

How AWRA opens up

As a technology partner you build on AWRA rather than just selling it. AWRA exposes its data and operations to integrators through APIs — programmatic access to read and write the records that run the business, within the same permissions and audit guarantees as the app.

Building on a governed platform means your integration inherits its controls. Access is authenticated and scoped, and what your integration does is recorded on the same audit trail as everything else.

Concretely, that means your integration authenticates as its own scoped identity — not a shared super-user — reads and writes through documented endpoints, and shows up in the audit trail like any other actor. Design with that in mind: request only the scopes you need, handle credential and token refresh, and never assume your integration is exempt from the permission and approval rules that govern human users. An integration that quietly bypasses approvals is a liability, not a feature.

Key takeaways

  • Technology partners build on AWRA via its APIs.
  • APIs read and write records under the same permissions and audit.
  • Integrations inherit the platform’s controls.
  • Authenticate as a scoped identity, not a shared super-user.
02
Lesson 2 of 4 Reading 9 min

The sync hub

Many integrations are about keeping two systems in step — an accounting package, a marketplace, a logistics provider. The sync hub is where these connections are configured and monitored, so data flows both ways reliably and failures are visible rather than silent.

Visibility is the difference between an integration you trust and one you fear. A sync hub that surfaces what synced, what failed, and why turns integration from a black box into something operable.

Treat the sync hub as the operational dashboard for your integration: it shows the last successful sync, queued and failed items, and the reason for each failure. Build so that a failed item can be retried from the hub without creating a duplicate, and so a non-technical operator can tell at a glance whether today’s data flowed. That day-to-day operability is often what the customer is really paying for — the API is plumbing; the hub is the gauge.

Key takeaways

  • The sync hub configures and monitors system-to-system connections.
  • It keeps data flowing reliably and surfaces failures.
  • Visible sync status makes an integration trustworthy.
  • Make failed items retryable from the hub without creating duplicates.
03
Lesson 3 of 4 Practice 11 min

Designing a reliable integration

A good integration is narrow, idempotent, and resilient: it does one job well, can safely retry without duplicating, and degrades gracefully when the other side is down. Design for the unhappy path — timeouts, partial failures, and rate limits — not just the demo.

The mark of a professional integration is what happens when things go wrong. Handling retries and conflicts cleanly is what separates a marketplace-grade build from a fragile script.

A practical checklist: use idempotency keys so a retried request never double-posts; back off and respect rate limits rather than hammering the API; reconcile periodically (not only on events) to catch anything missed; and log enough context to diagnose a failure without the customer on the phone. Assume the network, the other system, and your own process will each fail at some point — and decide in advance exactly what happens when they do.

Key takeaways

  • Keep integrations narrow, idempotent, and resilient.
  • Design for timeouts, partial failures, and rate limits.
  • Clean failure handling separates pro builds from fragile scripts.
  • Use idempotency keys and periodic reconciliation, not just event handling.
04
Lesson 4 of 4 Reading 9 min

Going to the marketplace

A finished integration can be listed in the AWRA marketplace, subject to the developer and marketplace policies. Listing means documenting what it does, how it is configured, and how it handles data — so customers can adopt it with confidence.

The marketplace is distribution. A well-documented, policy-compliant listing turns your build from a one-client custom job into a product other customers can discover and install.

A strong listing answers the questions a buyer asks before installing: what exactly does it sync, what data does it touch, how is it configured, what does it cost, and who supports it. Include setup steps, the permissions it requires, and a support contact. The clearer the listing, the fewer support tickets you field and the faster customers self-serve — which is the whole point of productising an integration rather than rebuilding it per client.

Key takeaways

  • Finished integrations can be listed in the marketplace.
  • Listing requires clear docs and policy compliance.
  • The marketplace turns a custom build into a discoverable product.
  • List required permissions, setup steps, costs, and a support contact.

Finished the material?

Take the 5-question assessment and earn your certificate — 80% to pass.

Take the assessment

Help Center

Need a quick answer while you read?

Run inventory, procurement, assets, sales, and field work with approved AWRA guidance for setup, migration, integrations, security, pricing, and support.

Search all approved AWRA public help articles.

Open Help Center