Resource identifiers

Every iGUIDE you create through the API comes with a set of identifiers — IDs that let you track, reference, and correlate iGUIDEs with your own systems. Knowing which IDs to store and how they relate to each other is the foundation of a reliable integration. This guide answers the question every integrator asks: "What should I store on my side?"

Core identifiers

The following table describes the primary identifiers operators encounter when working with the API.

Identifier	Format	Example	Immutable	Description
iGUIDE ID	ig + alphanumeric	igFKUNRGC5V8DD1	Yes	Uniquely identifies an iGUIDE. Returned as id when creating an iGUIDE and as iguideId in webhook payloads. This is the primary key you should store.
View ID	v + alphanumeric	vFKUNRGC5V8DD1	Yes	Uniquely identifies a View of an iGUIDE. The default view ID is returned as defaultViewId when creating an iGUIDE.
Work Order ID	Alphanumeric	Z1T9	Yes	Uniquely identifies a work order. Returned as workOrderId when creating an iGUIDE and in work order API responses.
iGUIDE Alias	URL slug	200-university-ave-waterloo-ca	No	Human-readable URL slug derived from the property address. Used in public URLs (https://youriguide.com/<alias>). Can change if the address is updated or on deletion.
Stitch Data ID	Alphanumeric	4MN	Yes	Identifies an uploaded Stitch TAR file. Returned when requesting an upload permit.

warning

The iGUIDE alias is a mutable identifier. Do not use it as a foreign key in your database. Always use the iGUIDE ID (igXXX) as your primary correlation key.

What to store

The table below summarizes what you should persist in your own system.

Field	Store?	Why
iGUIDE ID (id)	Yes — primary key	Immutable. Use this as your foreign key to correlate iGUIDEs with your own records.
Default View ID (defaultViewId)	Yes	Immutable. Needed to construct the public iGUIDE URL and to access view-specific endpoints.
Work Order ID (workOrderId)	Yes, per work order	Immutable. Needed to poll work order status and track processing progress. Store one per work order you create.
iGUIDE Alias (alias)	Cache only	Mutable. Useful for constructing public URLs but can change. Refresh from the API if needed.
Stitch Data ID	Temporarily	Only needed during the upload flow. Can be discarded after processing completes.

tip

At minimum, store the iGUIDE ID. It is the only identifier you need to access all other resources — you can always look up the default view, work orders, and alias from the iGUIDE ID.

Entity relationships

Understanding how iGUIDE entities relate to each other helps you model your integration correctly.

iGUIDE to views

1 iGUIDE → 1 Default View + N Optional Views

• Every iGUIDE has exactly one default view, created automatically
• The default view cannot be deleted
• Additional views can be created for different audiences (e.g., branded, unbranded, protected)
• Each view has its own ID, expiration date, access controls, and branding

iGUIDE to work orders

1 iGUIDE → 1 Initial Work Order + N Additional Work Orders

• Every iGUIDE has exactly one initial work order, created automatically
• Additional work orders are created for add-on deliverables (CAD, 3D models, ESX)
• Each work order tracks independently through the processing lifecycle
• A work order belongs to exactly one iGUIDE (never shared across iGUIDEs)

Views and work orders are independent

• There is no direct relationship between views and work orders
• Views are presentation layers (how the iGUIDE is displayed)
• Work orders are processing units (what work is being done)

Relationships between iGUIDE, View, and Work Order entities.

Identifier formats

Identifiers follow a few distinct encoding conventions that you can recognize at a glance.

• Prefixed IDs (ig, v, p): iGUIDE, View, and Property IDs use a type prefix followed by alphanumeric characters. The prefix tells you the entity type at a glance.
• Plain alphanumeric IDs: Work Order, Stitch Data, and Webhook IDs are plain base-36 uppercase strings with no prefix. Their type is determined by context (which API endpoint returned them).
• UUID-based IDs: User IDs (u_ prefix) and Banner IDs (b_ prefix) use UUID format with a type prefix.

tip

All identifiers are case-sensitive. Store and compare them exactly as returned by the API.

Identifiers in API responses

Different API responses return overlapping identifiers under different field names. The examples below show what to expect from the key endpoints.

Create iGUIDE Response (Create a New iGUIDE - POST /api/v1/iguides):

{
  "id": "igFKUNRGC5V8DD1",
  "alias": "200-university-ave-waterloo-ca",
  "workOrderId": "Z1T9",
  "defaultViewId": "vFKUNRGC5V8DD1"
}

Ready Webhook Event:

{
  "type": "ready",
  "iguideId": "igFKUNRGC5V8DD1",
  "defaultViewId": "vFKUNRGC5V8DD1",
  "iguideAlias": "200-university-ave-waterloo-ca",
  "workOrderId": "Z1T9"
}

Create Work Order Response (Create a Work Order - POST /api/v1/iguides/{id}/workOrders):

{
  "id": "Z1T8",
  "status": "on_hold",
  "iguideId": "igFKUNRGC5V8DD1"
}

tip

Note that the same identifier may appear under different JSON field names depending on the context. For example, the iGUIDE ID is id in the iGUIDE response but iguideId in webhook payloads and work order responses.

Integration patterns

The following patterns show how to apply identifier storage recommendations in common integration scenarios.

Pattern 1: Property listing platform

• Store iguideId as a foreign key on your listing record
• Store defaultViewId for embedding the iGUIDE Viewer
• Construct the public URL as https://youriguide.com/{alias} (cache the alias, refresh periodically)

Pattern 2: Automated processing pipeline

• Store iguideId to correlate with your property records
• Store workOrderId for each work order you create, to poll status
• Use the ready webhook to avoid polling overhead

Pattern 3: Multi-deliverable ordering

• Store iguideId as the parent key
• Store each workOrderId separately with the task types requested
• Track work order statuses independently — they complete at different times

warning

Never use the iGUIDE alias as a database key. It is derived from the property address and can change. Always use the iGUIDE ID.

Constructing URLs

Once you have stored the relevant identifiers, you can construct common URLs without making additional API calls.

URL Purpose	Pattern	Example
Public iGUIDE page	https://youriguide.com/{alias}	https://youriguide.com/200-university-ave-waterloo-ca
Embedded iGUIDE	https://youriguide.com/{alias}?embedded=true	https://youriguide.com/200-university-ave-waterloo-ca?embedded=true
Management page	https://manage.youriguide.com/iguides/{iguideId}	https://manage.youriguide.com/iguides/igAB3XR9M2
Non-default view	https://youriguide.com/{viewId}	https://youriguide.com/vFKUNRGC5V8DD1

tip

The default view uses the iGUIDE alias in its URL. Non-default views use their own View ID.

Related resources

• iGUIDE Lifecycle
• Work Order Lifecycle
• Create an iGUIDE