Skip to main content
Cookbook · Development

Populate a fresh instance from code

Developer ~30 min

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: jobsJobA high-level container, comparable to a project, that bundles related tasks together with common information such as customer, billing, and address. before tasksTaskA unit of work that belongs to a job. It appears in the open task list until it is scheduled to a resource., filter groupsFilter groupA configurable set of fields used to filter resources and tasks on the planning board. before filter valuesFilter valueA single value inside a filter group, used as a qualification on a resource or a requirement on a task., 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.

warning

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 connectorsConnectorAn integration that links Dime.Scheduler to a back-office system, routing data in and scheduling decisions back out. 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, Python, and Rust SDKs, the CLI for scripting and CI, or plain HTTP.

Point at the sandboxSandboxThe separate Dime.Scheduler environment where upcoming features arrive before the production release. It has its own API host, sandbox.api.dimescheduler.com, so API clients target it explicitly. for this exercise rather than production. You are about to create master data with a throwaway source appSource appAn identifier Dime.Scheduler attaches to data so it can route a change back to the correct back-office system., and you do not want that in a live tenant.

3. Create the master data​

In order:

  • ResourcesResourceAn entity that can carry out work - a person, vehicle, tool, or room - that you schedule on the planning board., 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 tasksOpen taskA task that has not been scheduled yet. It waits in the open task list to be placed on the planning board. 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 typeSource typeAn identifier that, together with the source app, tells Dime.Scheduler which back-office table a record belongs to. than the resources.

Last updated on by Hendrik Bulens