> ## Documentation Index > Fetch the complete documentation index at: https://docs.mf-atlas.space/llms.txt > Use this file to discover all available pages before exploring further. # Mailback Automation > Request CAMS mailback reports on demand or on a daily schedule — the reports that keep your investors' holdings up to date. Holdings (see [Investor Holdings](https://docs.mf-atlas.space/api-documentation/holdings.md)) are built from the reports **CAMS** and **KFintech** email to your registered mailback address. Mailback automation only **asks CAMS for those reports on a schedule** (or on demand), so nobody has to log in to CAMS and request them by hand. It does not receive anything: the report still arrives by email, and getting it into holdings needs the email forwarding below. > [!WARNING] > > **Set up email forwarding first — holdings depend on it.** Mailback automation > (and KFintech's own report subscription) only makes the registrar send an email. > For that email to reach this platform, the mailbox registered with the registrars > must **automatically forward** every CAMS and KFintech report email to > **`reports@mailbacks.mf-atlas.space`**. Without the forwarding rule, requests > succeed but no holdings are ever updated. See > [Email forwarding](#email-forwarding-required-for-holdings) below. > [!NOTE] > > Mailback automation is **switched on per account by your administrator**. Until > it is, every endpoint below returns `403 FORBIDDEN`. It also needs your > **mailback email** and **CAMS report password** to be configured on the account > — the automation logs in to CAMS with them. They are never returned by any > endpoint. Only **CAMS** is supported today; the `source` in each path is always `cams`. ## Email forwarding (required for holdings) CAMS and KFintech never send files to an API; they email a download link for a password-protected report to the distributor's registered email address. The platform picks those emails up from a single inbound address: ``` reports@mailbacks.mf-atlas.space ``` Set this up once per account, for **both CAMS and KFintech** mail, whether the CAMS reports are requested by the automation, by hand on CAMS Online, or by KFintech's own report subscription (KFintech reports are not requested by this automation — keep requesting them at KFintech): 1. **Make sure the registered email is configured on your account.** It is the `mailback email` your administrator set on the account, and it must be the address CAMS and KFintech actually send to. Emails are matched to your account by that address. 2. **In that mailbox, create an automatic forwarding rule** that forwards the registrar report emails to `reports@mailbacks.mf-atlas.space`. Forward (do not just redirect or copy by hand) so the original recipient address stays in the message headers. A filter on the sender domains (`camsonline.com`, `kfintech.com`) or on the subject ("Report No") keeps unrelated mail out; adjust it to what your mailbox really receives. 3. **Confirm the forwarding address** if your mail provider asks you to (many send a verification message to the new address). Ask your Atlas administrator for that verification message — it arrives on the platform side. 4. **Check it end to end:** request a `WBR4` report with `IMMEDIATE` timing (below; `WBR53` can only run overnight), wait for the CAMS email, and confirm it arrives in your mailbox and is forwarded. Folio contacts then appear on holdings after the next daily ingestion. > [!NOTE] > > The CAMS report password you give your administrator must match the one the > reports are protected with — it is what unlocks the file after it is received. > Only the `WBR53` (holdings) and `WBR4` (folio contacts) CAMS reports, and > KFintech's `MFSD203`, are ingested; other CAMS reports requested through the API > just land in your mailbox. ## How it works 1. You ask for a report — now (`POST …/requests`) or by saving a schedule (`PUT …/config`). 2. The request is queued and the API answers **immediately**. `status` is `QUEUED`; it only means the request was accepted for processing. 3. CAMS is asked for the report. It then **emails the report to your mailback address** — within minutes for `IMMEDIATE`, later for `OVERNIGHT`. Your [forwarding rule](#email-forwarding-required-for-holdings) passes it on to the platform. 4. `WBR53` and `WBR4` are ingested automatically and appear in holdings. Other reports are only emailed to you. There is no API call that returns the report file itself. `status: FAILED` means the request could not be queued at all; request it again. ## Reports and timing | Field | Values | | - | - | | `report` | Any CAMS report code listed in `available_reports` in the schedule response (the CAMS `WBR…` reports that need no extra input). `WBR53` (holdings) and `WBR4` (folio contacts) are the ones ingested into holdings; the others are simply emailed to your mailback address. | | `timing` | `IMMEDIATE` — CAMS mails the report within minutes. `OVERNIGHT` — CAMS prepares it overnight. A few complex reports (`WBR3`, `WBR12`, `WBR27`, `WBR35`, `WBR53`, `WBR54`) can only run `OVERNIGHT`; asking for `IMMEDIATE` returns `400 VALIDATION_FAILED`. | ## Request a report now ```http theme={null} POST /api/mailback-automation/v1/sources/cams/requests Authorization: Bearer Content-Type: application/json ``` ```json theme={null} { "report": "WBR53", "timing": "IMMEDIATE" } ``` Response `202`: ```json theme={null} { "success": true, "data": { "id": "mbr_3f2b8c1e-…", "source": "cams", "report": "WBR53", "timing": "IMMEDIATE", "trigger": "ON_DEMAND", "status": "QUEUED", "created_at": "2026-10-26T04:30:00Z" } } ``` | Status | Code | When | | - | - | - | | `400` | `VALIDATION_FAILED` | Unknown source, report or timing. | | `403` | `FORBIDDEN` | Mailback automation is not enabled for the account. | | `409` | `INVALID_STATE` | The mailback email or CAMS report password isn't configured. | ## Schedule Each account has **one schedule** for the source. Read it: ```http theme={null} GET /api/mailback-automation/v1/sources/cams/config Authorization: Bearer ``` Save it (this replaces the schedule): ```http theme={null} PUT /api/mailback-automation/v1/sources/cams/config Authorization: Bearer Content-Type: application/json ``` ```json theme={null} { "enabled": true, "reports": ["WBR53", "WBR4"], "timing": "OVERNIGHT", "run_at": "02:00", "days": ["MON", "TUE", "WED", "THU", "FRI"] } ``` Response `200`: ```json theme={null} { "success": true, "data": { "source": "cams", "enabled": true, "reports": ["WBR53", "WBR4"], "timing": "OVERNIGHT", "run_at": "02:00", "days": ["MON", "TUE", "WED", "THU", "FRI"], "last_enqueued_on": "2026-10-26", "updated_at": "2026-10-25T10:00:00Z", "available_reports": ["WBR2", "WBR2C", "WBR4", "…", "WBR53"] } } ``` | Field | Notes | | - | - | | `enabled` | A disabled schedule is kept but never runs. Enabling requires at least one report. | | `reports` | Requested on every run. | | `timing` | `IMMEDIATE` or `OVERNIGHT`, applied to every report in the run. | | `run_at` | `HH:MM`, 24-hour, **IST**. The schedule is checked every 15 minutes, so reports are requested within about 15 minutes after this time. | | `days` | `MON`…`SUN`. Empty means every day. | | `last_enqueued_on` | IST date the schedule last requested its reports. Read-only. Each schedule runs **at most once a day**. | With no schedule saved, `GET` returns a disabled default (`OVERNIGHT`, `02:00`). ## Request history ```http theme={null} GET /api/mailback-automation/v1/sources/cams/requests?limit=25 Authorization: Bearer ``` Returns the account's requests, newest first — both on-demand (`trigger: ON_DEMAND`) and from the schedule (`trigger: SCHEDULED`) — with `next_cursor` for the next page (pass it as `cursor`). A `FAILED` request carries an `error` message. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.