Authentication

Rendering needs no API key. Both endpoints are open: build a URL, request it, get a map. Nothing on this site requires an account to reproduce.

API keys do exist, but they buy exactly one thing, described below.

What a key does

A key decides whether the maproll wordmark can be turned off for renders tagged as coming from the maproll MCP server (src=mcp). Those renders carry the wordmark unless the request presents a valid key.

That is the whole entitlement. A key does not raise a limit, enable a parameter, change the image, or grant access to anything that is otherwise refused. For every other caller — a plain <img> embed, a curl, the editor — logo=false already works without a key. See Attribution & logo.

Where to pass a key

Either header works:

Authorization: Bearer mr_live_…

X-Api-Key: mr_live_…

A key is never read from the query string, and that is deliberate: a key in a URL ends up baked into whatever embed someone shares.

Keys are minted from the API keys panel in the maproll editor. They are prefixed mr_live_. The full key is shown once, at creation, and cannot be recovered afterwards. Each key expires 90 days after it is minted.

For the MCP server, the key goes in the environment as MAPROLL_API_KEY rather than in a header — the server signs the URLs it returns so that an <img> embed can be keyed without carrying the key. See Install.

How a key is verified

By signature, not by a lookup. The API recomputes the HMAC over the request and compares; it never reads a key table. That keeps the render path stateless, and it has one consequence worth planning around: revoking is not immediate. Deleting a key in the editor removes it from the panel and stops it signing anything new, but requests already signed with it keep verifying until the key's 90 days are up.

The same applies to expiry in the other direction. When a key expires, an MCP-made embed URL you published months ago starts carrying the wordmark again. Rotate before the 90 days are out, and re-render anything keyed that is already published.

What a key changes about caching

Where the key travels decides this:

Request	Cache-Control
Anonymous	public, max-age=31536000, immutable
Key in a header	private, no-store
MCP-signed URL (k and t)	public, max-age=31536000, immutable

Shared caches key on the URL and not on headers, so a header-keyed response must never be storable by one — otherwise a single keyed request would warm the edge with an un-watermarked map that every anonymous caller of the same URL would then receive.

A signed URL is the opposite case, and it is the reason the MCP server signs URLs instead of sending a header. The entitlement is part of the URL, so no cache entry can mismatch it, and the response stays immutably cacheable — which is what makes a keyed map safe to embed at scale. Calling the render API directly with a header key is the path that gives up caching.

Rate limits

None are enforced today. The render API ships no rate-limiting middleware and no per-key quota. This is a statement about what is currently implemented, not a promise that it will stay that way — do not build anything that depends on unlimited render throughput.

Fair use today

While the service is open:

• Renders are aggressively cached. Re-using the same URL is free — please do.
• Avoid generating thousands of unique URLs in a loop. Each distinct URL is a fresh render.
• PNG output costs meaningfully more CPU than SVG, because the SVG is rasterized server-side. Prefer .svg where the embedding context supports it.