Skip to main content

Quickstart

Every planning request uses a bearer credential. Trial credentials have an expiry, allowed operations, rate limits, total request allowances, road-matrix work limits, and solve-time ceilings.

Before you start​

You need curl and a bearer credential issued by Haladir. The examples below use synthetic operating data.

export SIMEONS_API_URL="https://api.simeons.haladir.com"
export SIMEONS_API_KEY="your-trial-key"

Keep the credential outside source control and application logs. The API never needs the source platform's PTV or Hexaly credentials.

Generate a driver manifest​

The documentation service provides a synthetic one-day scenario because a complete operating snapshot is too large to make a useful inline shell example. It contains two customer deliveries, two Nuggets, one driver, and one lorry. Its dates are generated for the next operating day; it is not live business data.

curl --silent --show-error --fail \
  --output manifest-request.json \
  "$SIMEONS_API_URL/docs/examples/manifest-request.json"

curl --silent --show-error --fail-with-body \
  --max-time 60 \
  --request POST "$SIMEONS_API_URL/v1/manifests" \
  --header "Authorization: Bearer $SIMEONS_API_KEY" \
  --header "Content-Type: application/json" \
  --data-binary @manifest-request.json \
  --output manifest-response.json

A full manifest request is a batch solve and may take tens of seconds. The HTTP timeout should exceed the solve allowance shown by the trial-usage route.

The response contains one entry in manifests for each assigned driver, any unplanned_movements, technical evidence, and planning notices. If jq is installed, this command prints a short result summary:

jq '{
  manifests: (.manifests | length),
  unplanned_movements: (.unplanned_movements | length),
  planning_engine: .evidence.planning_engine,
  validation: .evidence.validation
}' manifest-response.json

For the supplied scenario, a successful result contains a driver manifest, no unplanned movements, and validation set to passed. Exact activity times can change with road data and solver improvements.

Check a proposed booking​

The booking check uses the same operating snapshot plus new_movements. It is the bounded capacity check used before a full manifest replan.

curl --silent --show-error --fail \
  --output booking-check-request.json \
  "$SIMEONS_API_URL/docs/examples/booking-check-request.json"

curl --silent --show-error --fail-with-body \
  --max-time 30 \
  --request POST "$SIMEONS_API_URL/v1/booking-checks" \
  --header "Authorization: Bearer $SIMEONS_API_KEY" \
  --header "Content-Type: application/json" \
  --data-binary @booking-check-request.json \
  --output booking-check-response.json

Read Manifests and evidence before turning status into a booking decision: unknown does not mean that the booking is impossible.

Visual inspection​

The Playground builds the same requests with a form, shows the exact JSON and cURL, submits the request, and renders the returned schedule. It uses synthetic data and does not change source-platform records.

See Authentication and trial limits for credential usage, Errors and retries for failure handling, or the API reference for every field.