acme-backoffice-api

name

acme-backoffice-api

description

How to read ACME back-office data with the AcmeAccessService SDK (from @peektravel/app-utilities) — the concrete ACME capability surface and the data rules around it. Use when calling the ACME API (activities, which come from published event templates), and for ACME's capability ceiling (the typed SDK is the hard limit — no direct-API escape hatch), the published-templates and no-tickets facts, installDataId scoping, and PII handling. The installed package's own type definitions are the authoritative SDK surface — read them (see javascript-app-utilities). Triggers on "ACME API", "AcmeAccessService", "getAllActivities on acme", "acme activities", "event templates", "acme SDK methods", "AcmeApiError", "acme capability boundary".

Talking to the ACME back-office API

This is the concrete ACME data mechanism. The generic discipline — use the platform's official SDK, never a raw client; minimize PII; discover capabilities from the installed SDK rather than assuming — lives in backoffice-data. Read that for the why; this skill is the authoritative how it works on ACME.

Authenticated requests get a ready-to-use, install-scoped AcmeAccessService instance (called acme by convention). The auth pipeline builds it for you: a route under the ACME tree wrapped in withAppAuthentication<AcmeAccessService> receives the authenticated acme client as its second argument (see acme-embed-and-auth).

// app/examples/acme/main/api/<thing>/route.ts
import { type NextRequest, NextResponse } from "next/server";
import {   }  ;
 { withAppAuthentication }  ;

   = withAppAuthentication<>(
   (: , : ) => {
     activities =  acme.();
     .({ activities });
  },
);