# Carrying your own reference and routing

### Carrying your own reference and routing
Two optional form fields let a CRM / ERP hand over the context Mercura
cannot infer from the files:
| Field | What it does |
|  --- | --- |
| `custom_fields` | JSON object of your organisation's custom fields, keyed by the field's **label** — e.g. `{"Case Number": "00012345"}`. Comes back unchanged as `request_custom_fields` on `GET /tenders/{tender_id}`. |
| `branch` | Name of the Mercura branch (Niederlassung), matched case-insensitively. Routes the tender to the team that works that branch. |

Both are validated against your organisation's configuration **before** the
job is created, so a typo is a plain `400` with no job and no half-created
tender: an unknown branch name, an unknown custom-field label, or a
duplicate branch name all fail fast. This is deliberately stricter than
`customer_id` — a tender that lands unrouted or without its case number is
invisibly wrong, which is worse than a rejected upload.

```bash
curl -X POST https://prod-euapi.mercura.ai/api/public/v1/tenders \
  -H "Authorization: Bearer $MERCURA_API_KEY" \
  -H "Idempotency-Key: case-00012345" \
  -F "files=@Leistungsverzeichnis.x83" \
  -F "name=Neubau Bürogebäude Nord" \
  -F "branch=Niederlassung München" \
  -F 'custom_fields={"Case Number": "00012345"}'
```
Store the `request_id` that `GET /jobs/{job_id}` returns: it is the
`tender_id` for every later call, and the stable handle to correlate the
tender with the record on your side.
The upload is accepted in seconds; the job stays `RUNNING` until the
**processing pipeline finishes** (typically a few minutes). Learn the
outcome by polling `GET /jobs/{job_id}` until `status` is
`COMPLETED` / `FAILED`.

Version: 1.79.2

## Description:

  - `Carrying your own reference and routing` ()
    Two optional form fields let a CRM / ERP hand over the context Mercura
cannot infer from the files: | Field | What it does |
|  --- | --- |
| `custom_fields` | JSON object of your organisation's custom fields, keyed by the field's **label** — e.g. `{"Case Number": "00012345"}`. Comes back unchanged as `request_custom_fields` on `GET /tenders/{tender_id}`. |
| `branch` | Name of the Mercura branch (Niederlassung), matched case-insensitively. Routes the tender to the team that works that branch. | Both are validated against your organisation's configuration **before** the
job is created, so a typo is a plain `400` with no job and no half-created
tender: an unknown branch name, an unknown custom-field label, or a
duplicate branch name all fail fast. This is deliberately stricter than
`customer_id` — a tender that lands unrouted or without its case number is
invisibly wrong, which is worse than a rejected upload. ```bash
curl -X POST https://prod-euapi.mercura.ai/api/public/v1/tenders \
  -H "Authorization: Bearer $MERCURA_API_KEY" \
  -H "Idempotency-Key: case-00012345" \
  -F "files=@Leistungsverzeichnis.x83" \
  -F "name=Neubau Bürogebäude Nord" \
  -F "branch=Niederlassung München" \
  -F 'custom_fields={"Case Number": "00012345"}'
``` Store the `request_id` that `GET /jobs/{job_id}` returns: it is the
`tender_id` for every later call, and the stable handle to correlate the
tender with the record on your side. The upload is accepted in seconds; the job stays `RUNNING` until the
**processing pipeline finishes** (typically a few minutes). Learn the
outcome by polling `GET /jobs/{job_id}` until `status` is
`COMPLETED` / `FAILED`.