A sala de espera virtual empresarial

Início rápido: em direto em menos de 2 minutos

Proteja a sua aplicação em menos de 2 minutos: copie a tag do script para o seu head ou publique o link da gateway. Sem alterações na infraestrutura do seu servidor. Só quando pretende o máximo controlo é que ativa os recursos avançados opcionais – tudo o resto nesta página é exatamente isso: profundidade opcional para mais tarde.

1. 1

   Crie uma sala de espera

   Na consola de administração ADITUS: nome, morada da loja, taxa de admissão por minuto. Os padrões sensatos cobrem todo o resto.

2. 2

   Copiar uma linha

   Publique o link do gateway pronto em vez do link da loja – ou cole a etiqueta de script preparada na página da loja, exatamente como um snippet analítico.

3. 3

   Concluído — a fila está montada

   Abaixo da taxa de admissão, os visitantes nunca veem a sala de espera. Só quando ocorre um pico é que entra a fila – alojada, dimensionada e operada por nós.

Cresce consigo: três níveis de proteção

O poder da fila é um caminho de atualização, não um requisito. O nível 1 cobre sozinho a grande maioria dos casos de utilização.

Integração: duas opções

Qual a opção que se enquadra depende de uma questão: o link da loja publicada pode ser alterado? Se sim, o link da gateway é a melhor escolha – o tráfego nunca chega à loja antes da admissão. Se o URL da loja publicada for fixo, a tag script protege a loja sem qualquer alteração na sua publicação. Para além destes dois, a verificação pode ser aplicada no proxy reverso ou CDN (abaixo), conduzida diretamente pela API REST ou verificada em qualquer linguagem de back-end com uma biblioteca JWT – Node.js, PHP, Java,.NET, Python, Go.

Opção A: a ligação do gateway (recomendada)

Cada sala de espera fornece o seu próprio URL de entrada. É publicado em todos os locais onde o link da loja apareceria – newsletter, site, redes sociais. A fila recebe o pedido e decide do lado do servidor num único passo: abaixo da taxa de admissão o visitante é encaminhado diretamente para o endereço da loja configurada e não se apercebe da fila; ultrapassada a tarifa, o visitante chega à sala de espera e é automaticamente encaminhado quando chega a sua vez. A loja em si não recebe tráfego antes da admissão – os pedidos são absorvidos antes de chegarem à infraestrutura da loja.

<!-- Der veröffentlichte Shop-Link zeigt auf die Queue statt auf den Shop: -->
<a href="https://developers.aditus.com/queue/<slug>/enter">Tickets kaufen</a>

Para esta opção, o endereço de destino da loja (Ziel-URL) deve ser configurado para a fila — é o endereço para onde os visitantes admitidos são encaminhados. Os visitantes admitidos chegam à loja com um token de admissão assinado no URL – um JWT HS256 padrão que a loja pode opcionalmente verificar offline no seu próprio back-end utilizando o segredo partilhado.A estrutura, os claims e um exemplo de backend estão documentados abaixo. Nota: o gateway protege o ponto de entrada publicado; os visitantes que conhecem diretamente o URL da loja podem ainda ignorá-lo. Se isto for importante, combine o link do gateway com a etiqueta do script ou verifique o token no backend da loja.

Opção B: a etiqueta de script

Quando o link da loja publicado não pode ser alterado, a integração é uma única etiqueta de script. É entregue juntamente com as páginas da loja – da mesma forma que um snippet analítico é entregue – e deve estar presente em todas as páginas que a sala de espera deve proteger. Recomenda-se a colocação no <head> com o atributo defer; a posição exata não é crítica.

<!-- Auf jeder zu schützenden Shop-Seite im <head>: -->
<script src="https://developers.aditus.com/queue/<slug>/embed.js" defer></script>

A etiqueta exata para uma sala de espera específica – com o slug correto já introduzido – está disponível na consola de administração do ADITUS por fila. O script realiza três verificações em cada carregamento de página:

1. 1

   Visitante possui um passe válido

   Nada acontece. O passe é guardado durante a sessão do navegador e o visitante utiliza a loja sem interrupções.

2. 2

   Visitante regressa da sala de espera

   O token de admissão no URL é verificado no servidor (subscrição, atribuição de fila, expiração). Se for válido, será armazenado um passe de sessão e o token será removido da barra de endereço. Os tokens inválidos ou expirados enviam o visitante de volta para a sala de espera.

3. 3

   Visitante não tem passe

   Se não estiver ninguém à espera, o visitante é admitido silenciosamente em segundo plano e permanece na página – a sala de espera nunca é mostrada. Só quando a taxa de admissão configurada for ultrapassada e houver formação de fila é que o visitante é redirecionado para a sala de espera; a página atual é passada como um URL de retorno validado, pelo que, após a admissão, o visitante acede exatamente à página originalmente solicitada.

Endurecimento: impondo admissão no proxy de borda

Ambas as opções acima referidas protegem o ponto de entrada publicado. Se a loja estiver inacessível sem admissão, mesmo para os visitantes que conhecem o seu URL diretamente, o cheque passa para a frente da loja – para o proxy reverso ou CDN que termina o seu tráfego. A lógica é sempre a mesma três passos: obter o token do parâmetro URL aditus_queue_token quando o visitante regressa da sala de espera e armazená-lo como um cookie; em cada pedido, verifique o token do cookie como um JWT HS256 padrão com o segredo partilhado (emissor aditus-queue, audiência do slug da fila, expiração); sem um token válido, redirecione para a sala de espera em https://developers.aditus.com/queue/ <slug>. A verificação está offline — o proxy nunca chama a fila e não acrescenta latência. Os esboços seguintes mostram o padrão para quatro ambientes comuns; adapte-os à sua configuração.

# Skizze: Nginx mit njs (js_import) — prüft den Zugriffs-Token als HS256-JWT
# direkt am Proxy, ohne Rückruf an die Queue. An die eigene Umgebung anpassen.

# nginx.conf:
#   env ADITUS_QUEUE_SECRET;
#   js_import queue from /etc/nginx/queue.js;
#   server {
#     location /       { js_content queue.gate; }
#     location @shop   { proxy_pass http://shop_backend; }
#   }

// /etc/nginx/queue.js:
const crypto = require('crypto');
const SLUG = '<slug>';
const SECRET = process.env.ADITUS_QUEUE_SECRET; // Shared Secret der Queue

function claims(token) {
  const p = token.split('.');
  if (p.length !== 3) return null;
  const sig = crypto.createHmac('sha256', SECRET)
    .update(p[0] + '.' + p[1]).digest('base64url');
  if (sig !== p[2]) return null;
  const c = JSON.parse(Buffer.from(p[1], 'base64url'));
  const ok = c.iss === 'aditus-queue' && c.aud === SLUG && c.exp > Date.now() / 1000;
  return ok ? c : null;
}

function gate(r) {
  const fromUrl = r.args.aditus_queue_token;
  const m = (r.headersIn.Cookie || '').match(/(?:^|;\s*)aditus_queue=([^;]+)/);
  const token = fromUrl || (m && m[1]);
  if (!token || !claims(token)) {
    // Kein gültiger Token -> zurück in den Warteraum
    r.return(302, 'https://developers.aditus.com/queue/' + SLUG);
    return;
  }
  if (fromUrl) {
    // Token aus der Rücksprung-URL in ein Sitzungs-Cookie übernehmen
    r.headersOut['Set-Cookie'] =
      'aditus_queue=' + fromUrl + '; Path=/; Secure; HttpOnly; Max-Age=600';
  }
  r.internalRedirect('@shop');
}

export default { gate };

# Skizze: Caddy mit dem jwtauth-Plugin (github.com/ggicci/caddy-jwt).
# Token kommt beim Rücksprung als ?aditus_queue_token=… oder danach als Cookie;
# jwtauth prüft beide Quellen. An die eigene Umgebung anpassen.
shop.example.com {
  route {
    jwtauth {
      sign_key {env.ADITUS_QUEUE_SECRET}
      sign_alg HS256
      from_query aditus_queue_token
      from_cookies aditus_queue
      issuer_whitelist aditus-queue
      audience_whitelist <slug>
      user_claims qnr
    }
    # Token aus der URL einmalig in ein Cookie übernehmen
    @rueckkehr query aditus_queue_token=*
    header @rueckkehr Set-Cookie "aditus_queue={http.request.uri.query.aditus_queue_token}; Path=/; Secure; HttpOnly; Max-Age=600"
    reverse_proxy shop_backend:8080
  }
  # Ohne gültigen Token: zurück in den Warteraum
  handle_errors {
    @unauth expression {http.error.status_code} == 401
    redir @unauth https://developers.aditus.com/queue/<slug> 302
  }
}

// Skizze: Cloudflare Worker vor dem Shop — prüft den HS256-JWT offline per
// WebCrypto. Secret als Worker-Secret ADITUS_QUEUE_SECRET hinterlegen.
const SLUG = "<slug>";
const ROOM = "https://developers.aditus.com/queue/" + SLUG;

export default {
  async fetch(req, env) {
    const url = new URL(req.url);
    const fromUrl = url.searchParams.get("aditus_queue_token");
    const m = (req.headers.get("Cookie") || "").match(/(?:^|;\s*)aditus_queue=([^;]+)/);
    const token = fromUrl || (m && m[1]);
    if (!token || !(await valid(token, env.ADITUS_QUEUE_SECRET))) {
      return Response.redirect(ROOM, 302); // zurück in den Warteraum
    }
    if (fromUrl) {
      // Token in ein Cookie übernehmen und die URL bereinigen
      url.searchParams.delete("aditus_queue_token");
      return new Response(null, {
        status: 302,
        headers: {
          Location: url.toString(),
          "Set-Cookie": "aditus_queue=" + token +
            "; Path=/; Secure; HttpOnly; Max-Age=600",
        },
      });
    }
    return fetch(req); // gültiger Pass -> durch zum Shop
  },
};

async function valid(token, secret) {
  const p = token.split(".");
  if (p.length !== 3) return false;
  const key = await crypto.subtle.importKey(
    "raw", new TextEncoder().encode(secret),
    { name: "HMAC", hash: "SHA-256" }, false, ["verify"],
  );
  const ok = await crypto.subtle.verify(
    "HMAC", key, b64url(p[2]),
    new TextEncoder().encode(p[0] + "." + p[1]),
  );
  if (!ok) return false;
  const c = JSON.parse(new TextDecoder().decode(b64url(p[1])));
  return c.iss === "aditus-queue" && c.aud === SLUG && c.exp > Date.now() / 1000;
}

function b64url(v) {
  return Uint8Array.from(
    atob(v.replace(/-/g, "+").replace(/_/g, "/")),
    (ch) => ch.charCodeAt(0),
  );
}

// Skizze: AWS CloudFront mit Lambda@Edge (Viewer-Request, Node.js).
// Gleiches Muster: Token aus ?aditus_queue_token oder Cookie, HS256 offline
// prüfen, ohne gültigen Token in den Warteraum umleiten.
// Hinweis: Lambda@Edge hat keine Umgebungsvariablen — das Secret z. B. beim
// Deployment einbetten oder aus SSM/Secrets Manager cachen.
'use strict';
const crypto = require('crypto');
const SLUG = '<slug>';
const ROOM = 'https://developers.aditus.com/queue/' + SLUG;
const SECRET = '<ADITUS_QUEUE_SECRET>';

exports.handler = async (event) => {
  const req = event.Records[0].cf.request;
  const qs = new URLSearchParams(req.querystring || '');
  const fromUrl = qs.get('aditus_queue_token');
  const cookie = (req.headers.cookie || []).map((h) => h.value).join('; ');
  const m = cookie.match(/(?:^|;\s*)aditus_queue=([^;]+)/);
  const token = fromUrl || (m && m[1]);

  if (!token || !valid(token)) {
    return redirect(ROOM); // zurück in den Warteraum
  }
  if (fromUrl) {
    // Token in ein Cookie übernehmen und die URL bereinigen
    qs.delete('aditus_queue_token');
    const clean = req.uri + (qs.toString() ? '?' + qs.toString() : '');
    return redirect(clean, {
      'set-cookie': [{ key: 'Set-Cookie', value:
        'aditus_queue=' + token + '; Path=/; Secure; HttpOnly; Max-Age=600' }],
    });
  }
  return req; // gültiger Pass -> durch zum Shop (Origin)
};

function valid(token) {
  const p = token.split('.');
  if (p.length !== 3) return false;
  const sig = crypto.createHmac('sha256', SECRET)
    .update(p[0] + '.' + p[1]).digest();
  const got = Buffer.from(p[2], 'base64url');
  if (got.length !== sig.length || !crypto.timingSafeEqual(sig, got)) {
    return false;
  }
  const c = JSON.parse(Buffer.from(p[1], 'base64url'));
  return c.iss === 'aditus-queue' && c.aud === SLUG && c.exp > Date.now() / 1000;
}

function redirect(location, extraHeaders) {
  return {
    status: '302',
    headers: Object.assign(
      { location: [{ key: 'Location', value: location }] },
      extraHeaders || {},
    ),
  };
}

Nota: com a aplicação de limites em vigor, cada visitante precisa de um token – incluindo aqueles que, de outra forma, passariam silenciosamente abaixo da taxa de admissão. Publique o link do gateway (opção A) ao lado ou deixe o proxy redirecionar os visitantes sem token para a sala de espera, que emite um token imediatamente enquanto ninguém está à espera.

Detalhes técnicos

As secções seguintes não são necessárias para a integração — a etiqueta de script acima está completa. Documentam como funciona o sistema para avaliação técnica e para lojas que desejam verificar a admissão no seu próprio backend.

Como funciona a admissão

Cada visitante recebe um número de espera sequencial por um único incremento atómico da base de dados. A admissão avança continuamente: o número atualmente admitido é calculado como base + taxa × minutos decorridos. A pesquisa de estado é de leitura apenas e não afeta a base de dados por pedido. Não há estado por visitante no servidor, nem cron job nem cronómetro — o próprio serviço de fila não se pode tornar um estrangulamento sob carga. A pausa na fila impede tanto a admissão como a emissão de novos números; as alterações das taxas entram em vigor continuamente e o número admitido nunca diminui.

Justiça: estritamente primeiro a chegar, primeiro a ser servido

A admissão é estritamente por ordem de chegada (FCFS): o incremento atómico fixa a posição de cada visitante no momento da adesão, e as posições nunca mudam posteriormente. Não há deliberadamente nenhuma lotaria, nenhuma randomização e nenhuma faixa de prioridade – sob escassez, a ordem de chegada é a única ordem que os visitantes aceitam como justa, e é a única que não pode ser manipulada. O salto na fila é tecnicamente excluído em dois níveis: o número de espera só aumenta e a verificação de admissão compara o número do visitante com o número atualmente admitido no servidor – o token de admissão só é emitido quando a verificação é aprovada, assinada com o segredo da fila. Um visitante não pode reivindicar uma posição melhor e um token forjado falha a verificação de assinatura. Os operadores que necessitam de fluxos separados — digamos, uma sala de espera por evento ou por venda — gerem várias salas de espera independentes, cada uma com o seu próprio slug, segredo, taxa e configuração.

Arquitetura sob carga: números medidos

O objetivo do design segue diretamente da lógica de admissão acima: como o número admitido é derivado do tempo decorrido e a verificação do estado não indica qualquer estado por visitante, quase todo o tráfego de visitantes é uma computação sem estado. Qualquer instância pode responder a qualquer pedido, as instâncias não partilham nada para além da base de dados e a plataforma adiciona automaticamente instâncias sob carga. A gravação única da base de dados por visitante — o incremento atómico na junção — é o único ponto de serialização e acontece exatamente uma vez por visitante, e não por sondagem. Os números abaixo provêm do executor de teste de carga integrado descrito acima, executado contra uma sala de espera de teste dedicada no sistema de produção: dois workers geradores solicitam duas instâncias de fila, sendo o débito e a taxa de erro retirados dos recibos assinados do serviço de fila. O perfil mix combina a adesão e a pesquisa de estado na proporção do percurso real do visitante:

Todas as execuções utilizaram o percurso do código de produção e terminaram sem um único erro HTTP, de transporte ou de limite de taxa. Duas instâncias sustentam mil pedidos de estado por segundo durante dois minutos – mais de dez mil visitantes em espera a consultar no seu intervalo adaptativo – e o perfil mix confirma que quinhentos pedidos por segundo, adesões incluídas, passam sem serem travados pelos orçamentos de pedidos por IP. O topo da tabela é limitado pelo gerador de carga, não pela fila: o p95 do lado da fila manteve-se em milissegundos de um dígito até o gerador funcionar no máximo. Este dimensionamento não é uma caixa negra: cada instância em execução reporta continuamente com métricas em tempo real – CPU, memória, taxa de transferência de pedidos – visíveis a qualquer momento na consola de administração do ADITUS, pelo que é transparente quantas instâncias estão à venda e quanto espaço resta. Os testes de carga programados verificam novamente estes números continuamente em relação ao sistema de produção, e uma execução que fica claramente atrás dos seus antecessores é automaticamente sinalizada.

Endpoints

Dez endpoints, sem autenticação para visitantes, CORS restrito aos domínios configurados por fila. A página alojada da sala de espera utiliza exatamente esta API – também pode ser direcionada diretamente para uma experiência de espera totalmente personalizada.

1.º Solicite um número de espera

// Wartenummer anfordern (einziger Schreibzugriff im Besucherpfad).
const res = await fetch("https://developers.aditus.com/queue/<slug>/join", {
  method: "POST",
});
const ticket: {
  queue: string;              // Queue-Slug
  name: string;               // Anzeigename des Warteraums
  number: number;             // vergebene Wartenummer
  serving: number;            // bis zu dieser Nummer wird weitergeleitet
  ahead: number;              // Anzahl Nummern vor dieser
  admitted: boolean;          // true -> sofort weiter zu /token
  estimatedWaitSeconds: number;
  retryAfterSeconds: number;  // empfohlenes Polling-Intervall
} = await res.json();
// 423 Locked -> der Warteraum ist pausiert (keine Weiterleitung, keine neuen Nummern).

2.º Pesquise o estado

// Statusabfrage — rein lesend, beliebig oft wiederholbar.
// Der Server sendet zusätzlich einen Retry-After-Header.
const res = await fetch(
  "https://developers.aditus.com/queue/<slug>/status?number=" + ticket.number,
);
const status: {
  queue: string;
  name: string;
  active: boolean;            // false -> Weiterleitung pausiert
  number: number;
  serving: number;
  ahead: number;
  admitted: boolean;
  estimatedWaitSeconds: number;
  retryAfterSeconds: number;
} = await res.json();

if (status.admitted) {
  // -> Token abholen und zum Shop weiterleiten
}

3.º Obtenha o token de admissão

// Sobald admitted=true: Zugriffs-Token abholen.
const res = await fetch("https://developers.aditus.com/queue/<slug>/token", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ number: ticket.number }),
});
// 425 Too Early -> die Nummer ist noch nicht zur Weiterleitung freigegeben.
const grant: {
  queue: string;
  number: number;
  token: string;              // signierter HS256-JWT
  tokenType: "JWT";
  expiresInSeconds: number;   // Standard: 600 s
  targetUrl: string | null;   // konfiguriertes Weiterleitungsziel
} = await res.json();

// Weiterleitung übernimmt die gehostete Warteraum-Seite automatisch:
// targetUrl + "?aditus_queue_token=" + grant.token

Opcional: verificando o token no seu back-end

A integração da tag script é completa por si só. As lojas que controlam o seu back-end também podem verificar o token de admissão: é um JWT HS256 padrão, verificado offline com o segredo partilhado – sem retorno de chamada para a fila, sem latência extra. O segredo é gerado quando a fila é criada, mostrado exatamente uma vez e pode ser alternado a qualquer momento. Reivindicações: iss é sempre aditus-queue, aud é o slug da fila, qnr é o número de espera admitido, exp limita a validade (padrão 10 minutos). Nota: a passagem silenciosa sob a taxa de admissão não produz um token – um back-end que exija estritamente um token deve enviar os visitantes sem ele para a sala de espera, que depois emite um token imediatamente quando ninguém está à espera.

// ZIELSYSTEM (dein Shop / deine Seite): Token prüfen — Standard-JWT (HS256).
// Das Secret erhältst du einmalig von ADITUS beim Einrichten des Warteraums.
import jwt from "jsonwebtoken";

const payload = jwt.verify(token, process.env.ADITUS_QUEUE_SECRET!, {
  algorithms: ["HS256"],
  issuer: "aditus-queue",     // iss ist immer aditus-queue
  audience: "<slug>",         // aud ist der Queue-Slug deines Warteraums
}) as { qnr: number; iat: number; exp: number };

// payload.qnr = die weitergeleitete Wartenummer.
// Gültiger Token -> Besucher passieren lassen (z. B. Cookie setzen).
// Fehlender/ungültiger Token -> zurück in den Warteraum:
//   https://developers.aditus.com/queue/<slug>

Segurança num só lugar

Os mecanismos de segurança estão descritos onde pertencem no fluxo acima; esta secção os recolhe. Tokens assinados: os tokens de admissão são JWTs HS256, assinados com um segredo por fila que é mostrado exatamente uma vez e pode ser alternado a qualquer momento; a ligação de público (slug de fila) e uma expiração curta (padrão 10 minutos) limitam o valor de um token capturado. Proteção de bot: a verificação opcional de prova de trabalho torna a adesão em massa de bot farms proporcionalmente dispendiosa; os desafios são assinados pelo HMAC e expiram ao fim de cinco minutos; uma proteção de melhor esforço por instância também suprime a reutilização de um desafio gasto – o verdadeiro gerador de custos é o próprio trabalho de hash. Redireccionamentos: Os URLs de retorno são validados no lado do servidor em relação aos domínios configurados por fila — a sala de espera nunca se torna um redireccionamento aberto. Superfície API: os endpoints dos visitantes não transportam qualquer credencial, o CORS é restrito por fila, o acesso do administrador utiliza chaves API que estão ligadas a uma única sala de espera, armazenadas apenas como hashes, não podem gerir outras chaves e deixar um rasto de auditoria. Picos de tráfego: a arquitetura stateless absorve a carga por design — qualquer instância responde a qualquer pedido e a plataforma escala as instâncias automaticamente; a filtragem DDoS ao nível da rede é fornecida pela plataforma de alojamento na parte frontal do serviço.

Modos de falha: o que acontece quando algo se parte

Uma sala de espera está diante da receita – o seu comportamento de fracasso é tão importante como o seu caminho feliz.

• Serviço de fila inacessível (variante script-tag): o script falha a abertura – a loja permanece totalmente utilizável. Uma interrupção na sala de espera nunca bloqueia a loja.
• Serviço de fila inacessível (variante gateway): pausa de novas entradas; os visitantes já admitidos estão na loja e mantêm-se inalterados.
• Perda de uma única instância: nenhum visitante se apercebe. Nenhum estado por visitante reside em nenhuma instância – cada instância responde a todos os pedidos, a base de dados partilhada é o único componente com estado.
• Atualização do browser: o número de espera é mantido na sessão do browser — uma recarga volta à mesma posição, o lugar na fila nunca é perdido.
• O visitante limpa os cookies ou o armazenamento do browser: a posição não é deliberadamente recuperável — o visitante sorteia um novo número no final da linha. Qualquer outra coisa abriria caminho para fraudes de posição.
• Sala de espera em pausa: paragem de entrada e admissão com sinal claro (HTTP 423) e mensagem explicativa na sala de espera — sem erros silenciosos.
• A verificação de integridade da loja falha (taxa automática): a taxa congela primeiro e depois desce para o mínimo configurado – uma verificação de integridade inacessível nunca abre mais as portas.

Como se compara com os produtos dedicados para salas de espera

O ADITUS-Queue aborda os mesmos problemas técnicos que os produtos dedicados de sala de espera virtual empresarial. A tabela mapeia as capacidades pelas quais estes produtos são medidos de acordo com a forma como o ADITUS-Queue os cobre – incluindo uma omissão deliberada.

Administração via chave API

Tudo o que a consola de administração ADITUS permite fazer numa sala de espera — ajustar a taxa de admissão, pausar ou alterar a configuração — também pode ser automatizado. O acesso utiliza uma chave de API com o prefixo qak_, enviada como Bearer token; cada chave é criada para uma única sala de espera e só pode ler ou alterar essa sala. As chaves são criadas e revogadas na consola de administração, apresentadas uma única vez e armazenadas apenas sob a forma de hash. Um caso de utilização típico é um runbook de início de vendas: uma tarefa agendada aumenta a taxa de admissão imediatamente antes da abertura, um script pausa a fila em caso de emergência e a monitorização lê a configuração atual. Aplicam-se três salvaguardas: uma chave nunca acede a outras salas de espera nem a funções administrativas globais (testes de carga, agendamentos ou instâncias), sendo esses pedidos rejeitados no servidor; a gestão das próprias chaves não é possível com uma destas chaves, pelo que uma chave exposta nunca pode criar nem listar outras; e todas as alterações efetuadas com uma chave são registadas no registo de auditoria com o nome da chave e da respetiva sala de espera.

# Konfiguration des zugeordneten Warteraums lesen. Jeder Key ist an genau
# einen Warteraum gebunden — die Liste enthält daher höchstens diesen einen
# Eintrag; andere Warteräume und globale Verwaltungsfunktionen sind mit
# einem Key nicht erreichbar.
curl -H "Authorization: Bearer qak_…" \
  https://developers.aditus.com/api/admin/queue/sites

# Weiterleitungsrate im laufenden Betrieb anheben: Lesen -> Feld ändern -> Schreiben.
# PATCH erwartet die vollständige Konfiguration (ohne slug); unbekannte
# Felder wie id oder Zeitstempel werden serverseitig ignoriert.
KEY="qak_…"; BASE="https://developers.aditus.com/api/admin/queue"
SITE=$(curl -s -H "Authorization: Bearer $KEY" "$BASE/sites" \
  | jq '.sites[0]')
echo "$SITE" | jq '.ratePerMinute = 300' | curl -s -X PATCH \
  -H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \
  -d @- "$BASE/sites/$(echo "$SITE" | jq -r .id)"

# Zugeordneten Warteraum pausieren (keine Weiterleitung, keine neuen Nummern):
# active = false
echo "$SITE" | jq '.active = false' | curl -s -X PATCH \
  -H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \
  -d @- "$BASE/sites/$(echo "$SITE" | jq -r .id)"

# .github/workflows/onsale.yml — Weiterleitungsrate zum Vorverkaufsstart anheben.
# Den API-Key als Repository-Secret ADITUS_QUEUE_API_KEY hinterlegen. Der Key
# ist an den Warteraum des Vorverkaufs gebunden — mehr kann er nicht.
name: Weiterleitungsrate zum On-Sale anheben
on:
  schedule:
    - cron: "55 8 14 3 *"   # 14. März, 08:55 UTC — kurz vor dem On-Sale
  workflow_dispatch: {}

jobs:
  raise-rate:
    runs-on: ubuntu-latest
    steps:
      - name: Rate auf 300/min anheben
        env:
          KEY: ${{ secrets.ADITUS_QUEUE_API_KEY }}
        run: |
          BASE="https://developers.aditus.com/api/admin/queue"
          # Der Key sieht nur seinen gebundenen Warteraum — .sites[0] genügt.
          SITE=$(curl -sf -H "Authorization: Bearer $KEY" "$BASE/sites" \
            | jq '.sites[0]')
          echo "$SITE" | jq '.ratePerMinute = 300' \
            | curl -sf -X PATCH \
              -H "Authorization: Bearer $KEY" \
              -H "Content-Type: application/json" \
              -d @- "$BASE/sites/$(echo "$SITE" | jq -r .id)"