Atlas as the backend for your own applications

Most businesses eventually want an interface Atlas doesn’t ship: a customer portal, a crew dashboard, a mobile app for the field. On the Enterprise tier, Atlas can act as the backend for those applications, giving each of them the same centralized data.

The idea

Instead of building a database for every application — each with its own copy of customers, properties and jobs, and its own validation rules — your applications use Atlas as their system of record.

• A customer portal shows a customer their properties and service requests.
• An internal dashboard shows the office every open request.
• A mobile app lets crews update a property’s records on site.

All three read and write the same records, with the same validation rules, because the rules live in your Atlas schemas.

What’s available

Everything you build in Atlas — modules, schemas, records, samples, documents — is available through its APIs. According to Atlas’s documentation, that means you can:

• Read and write records against your schemas, with the same validation the UI uses.
• Drive pipelines — start runs, satisfy directives, and read run state programmatically.
• Generate documents from templates on demand.
• Rely on namespace-scoped access that keeps API consumers inside the permissions you’ve set.

To make that easy, Atlas includes the Atlas API Client and the Atlas SDK for managing the data stored in Atlas, from classifications and schemas to individual records. Full API access is part of the Enterprise tier.

A small example

Here’s the shape of reading and creating records with the Atlas API Client. In the API, a topic is referred to as a subject; the calls take the topic’s ID and the record schema’s ID.

// `client` is an authenticated Atlas API Client.

// List the Property Profile records for one property.
const results = await client.data.search({
  subject_id: propertyId, // the topic, e.g. 42 Juniper Lane
  schema_id: propertyProfileId, // the record schema
  limit: 20,
});

// Add a record to the same property.
const record = await client.data.create({
  subject_id: propertyId,
  schema_id: propertyProfileId,
  name: 'Property Profile',
  data: {
    /* values for the record schema's fields */
  },
});

The client also offers get, update and archive for records, and dedicated clients for classifications, record schemas, data schemas, pipelines, work queues, documents and templates. The Atlas video series shows a customer portal page built this way, backed by Atlas — “same data, same validation, every app.”

Why this beats a database per app

One set of rules. Validation defined in a data schema applies to every application, not just the one whose developer remembered to add it.

No sync jobs. When the portal and the dashboard share records, there’s nothing to copy between them.

Governed access. Applications work inside the permissions you’ve set, so a portal can’t reach data it shouldn’t.

A model that evolves safely. Published schemas are versioned, so applications written against one version keep working when the model changes. See How schema versioning protects the data you’ve already collected.

Planning an integration

1. Model first. Build your classifications and record schemas in the Atlas interface before writing code. See Modeling your business in Atlas.
2. Use External IDs to match Atlas topics with records in systems you’re integrating. See External IDs and topic properties.
3. Plan your request volume. Enterprise includes 10,000,000 platform requests a month. See Understanding Enterprise platform requests.

A reference architecture

A common shape for teams building on Atlas:

• Atlas holds the model: classifications, schemas, topics, records, documents, and the permissions around them.
• Your applications — a customer portal, an internal dashboard, a field app — call Atlas through the Atlas API Client.
• Authentication determines who the caller is, and namespace-scoped access keeps each consumer inside the permissions you’ve set.
• Integrations with other systems match records through each topic’s External ID.

Notice what’s absent: a separate application database holding its own copy of customers and properties, and the sync jobs that would keep it aligned.

What to build in Atlas vs. in your app

Keeping rules in Atlas means every application inherits them, including ones you haven’t built yet.

Practical development tips

• Model first, code second. Build classifications and schemas in the interface, then write against them.
• Read schema and classification information once and cache it; it changes rarely.
• Use search with limits rather than fetching records individually in a loop.
• Handle versions deliberately. Published schemas are versioned, so pin your expectations and update when you’re ready.
• Log what you can’t match during integrations, instead of creating duplicates.
• Keep an eye on request volume — see Understanding Enterprise platform requests.

Frequently asked questions

Which tier includes API access? Full API access is part of the Enterprise tier.

Can several applications share one Atlas organization? Yes — that’s the point. A portal, a dashboard and a mobile app can all read and write the same records.

How do permissions work for an application? Namespace-scoped access keeps API consumers inside the permissions you’ve set.

Can applications drive processes, not just data? Yes. Atlas’s APIs let you start pipeline runs, satisfy directives and read run state.

Is there an SDK as well as an API client? Yes — Atlas includes both an API client and an SDK for managing the data stored in Atlas.

Further reading

• Master data management for small and mid-sized businesses
• Pipelines explained