Functions + Basket

Calling your project's Basket DB from a function.

Reaching your project's database

A function talks to Basket DB the same way any backend does: over the REST API, with a project key you provide as a secret variable.

Outbound network access is closed in V1, so a function cannot call the Basket API over HTTP yet. Until direct service binding ships, the pattern below is how a function and Basket cooperate: the function does the work it can do locally, and your own backend or frontend performs the Basket call. This page will document the binding the moment it is real.

The pattern today

// Function: validate and shape, return the record to write
return function (Request $request): Response {
    $input = $request->json() ?? [];
    $user  = $request->user();          // auth-mode function

    if (($input['destination'] ?? '') === '') {
        return Response::json(['error' => 'destination_required'], 422);
    }

    return Response::json(['record' => [
        'destination' => $input['destination'],
        'sender_id'   => $user['id'],
        'status'      => 'pending',
    ]], 201);
};

// Caller: write it to Basket with the user's own token, so rules apply
const shaped = await callFunction('create-shipment', payload);
await fetch(`${BASE}/collections/shipments/records`, {
  method: 'POST',
  headers: { ...pub, 'X-Basket-User-Token': session.access_token },
  body: JSON.stringify({ data: shaped.record })
});

Project boundaries hold either way

A project's key works only against that project's URL — holding project A's key and asking for project B is refused, whoever you are. So a function belonging to project A can never reach project B's data, whatever credential it is given.

What will not happen

Fareedah root passwords, Basket master keys and Auth signing secrets are never placed inside a customer runtime. When service binding ships it will be narrow and project-scoped, and preferably short-lived — not the platform's own credentials handed down.