Populate a fresh instance from code
A runnable walk-through for developers picking up the API for the first time. You'll create the master data (resources, filter groups and values, categories, time markers), then the transactional data (jobs and tasks), and finally the assignments - filter values on resources and tasks, indicators on jobs - so a fresh instance ends up with something planners can actually work with.
Before you start
The single most important thing about this flow is order. Parents must exist before children: jobs before tasks, filter groups before filter values, indicators before you assign them. Get the order wrong and calls fail in ways that look like authentication or schema problems but are not.
The second most important thing is that SourceApp and SourceType tie everything together. Pick a pair and reuse it across every record, or the relationships will not line up.
1. Get an API key
An API key proves that a process has permission to call the API. That is exactly the right fit here, and exactly why it is the wrong fit for a user-facing app: keys represent the integration as a whole and cannot represent a specific person. If you need per-user permissions or an audit trail of who did what, use OAuth instead.
Create the key from the API keys page, give it a name that identifies the calling system, and set an expiration.
The full key is shown once, at generation. Copy it into your secret store immediately. There is no way to retrieve it afterwards; a lost key has to be revoked and reissued.
Send it in the X-API-KEY header as the raw value, with no Bearer prefix, no quotes, and no whitespace.
2. Choose how you call the API
Everything is built on the REST API. The SDKs, the CLI, and the standard connectors are all wrappers around the same endpoints, so you can mix and match freely and drop to raw HTTP whenever you need to.
Available options are the .NET, JavaScript, and Python SDKs, the CLI for scripting and CI, or plain HTTP.
Point at the sandbox for this exercise rather than production. You are about to create master data with a throwaway source app, and you do not want that in a live tenant.
3. Create the master data
In order:
- Resources, the people or things being planned.
- A filter group and its filter values, so planners can filter by skill, region, or whatever dimension you choose.
- A category and a time marker to color-code the result.
4. Create the transactional data
Then the job, and the tasks beneath it. This is where the parent-before-child rule bites hardest, since a task without its job has nothing to attach to.
5. Create the assignments
Finally the links: filter values onto resources and tasks, indicators onto jobs. This is the step that turns a set of disconnected records into something a planner can actually use, and it is the step most often skipped in a first integration, which is why the data looks present but unusable.
6. Follow the guide
The end-to-end quickstart reproduces this exact flow with working code. It also carries an interactive walkthrough where you paste an API key, pick an environment, and get a ready-to-run curl command for each step. Your key stays in the browser; nothing is executed from the page.
Verify
Open the planning board and confirm the resources appear as rows and the tasks show up in the open tasks grid, ready to plan.
That last part is the real test. Records that exist in the database but never reach the open tasks grid usually means the task was created without the assignments from step 5, or under a different source app and source type than the resources.
Related
- Extend the appointment card with templates if you are pushing custom field values.
- Set up a webhook connector to receive events back out.