The manual for your board

What the Board is

A multi-brand support board: you serve YOUR customers, under YOUR brand, on our infrastructure.

The Support Board is a single case queue for your operation: your customers open cases from your website (widgets), through the API or by email, and your team handles them from a panel of their own at dash.elportaldelcliente.com. Every case comes in, moves forward and escalates while nobody is awake — but none concludes without a name behind it.

Your board is an isolated tenant: your cases, your end customers and your agents never mix with anyone else's. Isolation is part of the system's design, not a setting someone could forget. If our staff touches one of your cases as last-level support, the access is recorded and you can look it up.

Getting started

From zero to operating, in five steps.

1. Create your account at dash.elportaldelcliente.com.
2. Activate a plan. It is paid from your account balance (the same wallet used across the ecosystem); if you are short, the screen offers to top up exactly the difference.
3. Invite your agents in the “Agents” tab: email and role (agent or administrator). You will receive an access link to hand to them.
4. Turn on a widget in “Widgets & API”: register your website's domain as an authorized origin, copy the script and paste it into your site.
5. Integrating by code? Issue your tab_live_ credential in the same tab and follow the API reference on this page.

The board panel

The tenant panel at dash.elportaldelcliente.com, tab by tab.

The agents you invite see and handle your board's cases; administrators additionally manage the subscription, the team and the integrations.

Widgets for your website

Three widgets, one line of script each. No third-party iframes, no tracking cookies.

In your panel's “Widgets & API” tab: turn the widget on, register your site's domain as an authorized origin and copy the generated script. The data-color parameter accepts your brand color.

<script src="https://api.elportaldelcliente.com/api/tablero/widget/tablero.js"
        data-tenant="su-tablero" data-widget="contacto" data-color="#a177ff"></script>

Widget protections

Anonymous widgets accept 10 attempts per visitor (IP) every 10 minutes per board. If the widget is off, the origin is not authorized or the subscription has expired, the widget responds 404 widget no disponible — deliberately indistinguishable, so it never reveals your board's configuration.

The “board” widget: identifying your customer

The board widget shows each end customer only their own cases. To do that, your server redeems a short-lived token per customer: call POST /v1/clientes/:ref/token-widget with your API credential (server-side, never from the browser) and hand the token to the widget.

curl -X POST https://api.elportaldelcliente.com/api/tablero/v1/clientes/cli-842/token-widget \
  -H "Authorization: Bearer $TABLERO_KEY"

HTTP/1.1 201
{"success":true,"data":{"token":"tabw_…","expires_at":"2026-08-18 21:15:00"}}

window.TableroPortal.setToken(token);

API credentials

One Bearer credential per integration, with a narrow, revocable scope.

Credentials are issued in your panel (“Widgets & API” → “API credentials”). They take the form tab_live_… and are shown only once: store it in your secrets manager. We only keep its hash.

curl -H "Authorization: Bearer tab_live_…" \
  https://api.elportaldelcliente.com/api/tablero/v1/

When issuing one you can narrow its scopes. A credential without explicit scopes has access to your entire board:

• A maximum of 5 active credentials per board. Revoke the ones you no longer use.
• The credential identifies your board: never send tenant_id in the body — the API rejects it with 400.
• With an expired subscription the credential keeps reading (GET); every write responds 402 suscripcion_vencida.
• A revoked credential responds 401 immediately on every route.

API reference

REST over HTTPS, JSON in both directions, responses shaped {success, data}.

Conventions: request bodies go as Content-Type: application/json; dates are UTC YYYY-MM-DD HH:MM:SS; paginated listings return total, page and limit. Whatever is not yours responds 404, never 403: the API does not confirm the existence of other tenants' resources.

https://api.elportaldelcliente.com/api/tablero/v1

Root: identity, plan and usage

GET / is the contract that cannot lie: it returns who you are, which scopes this credential holds, your plan with its limits, your subscription status and how much you have used.

curl -H "Authorization: Bearer $TABLERO_KEY" \
  https://api.elportaldelcliente.com/api/tablero/v1/

{"success":true,"data":{
  "tenant":{"slug":"su-tablero","nombre":"Su Marca"},
  "scopes_de_esta_credencial":["casos.read","casos.write"],
  "plan":{"id":"tablero-base","nombre":"BASE","limites":{"max_agentes":5,"max_departamentos":5,"max_articulos_kb":100}},
  "suscripcion":{"estado":"active","current_period_end":"2027-08-18"},
  "uso":{"agentes":3,"departamentos":2},
  "recursos":["/casos","/clientes","/departamentos","/accesos","/webhooks"],
  "version":"v1"}}

End customers

An end customer is a customer of yours (not an account in our ecosystem). They are identified by external_ref: the ID that customer has in YOUR system.

curl -X POST https://api.elportaldelcliente.com/api/tablero/v1/clientes \
  -H "Authorization: Bearer $TABLERO_KEY" \
  -H "Content-Type: application/json" \
  -d '{"external_ref":"cli-842","email":"[email protected]","name":"Maria Rojas"}'

Cases

The central resource. A case has a status, a priority, an optional end customer and a conversation of replies. Agents' internal notes are never exposed through the API.

Create a case tied to an end customer:

curl -X POST https://api.elportaldelcliente.com/api/tablero/v1/casos \
  -H "Authorization: Bearer $TABLERO_KEY" \
  -H "Content-Type: application/json" \
  -d '{"subject":"No puedo entrar al panel","cliente_ref":"cli-842","priority":"high",
       "body":"Al iniciar sesion la pagina queda en blanco."}'

HTTP/1.1 201
{"success":true,"data":{"id":"…","numero":"SOLC-1051"}}

List with filters, and incremental sync with updated_since (ISO 8601): in that mode the order is updated_at ascending, designed to advance page by page without missing changes. Store the highest updated_at you processed and use it as the cursor for the next pass.

curl -H "Authorization: Bearer $TABLERO_KEY" \
  "https://api.elportaldelcliente.com/api/tablero/v1/casos?estado=open&cliente=cli-842&limit=50&page=1"

# incremental sync (order: updated_at ascending)
curl -H "Authorization: Bearer $TABLERO_KEY" \
  "https://api.elportaldelcliente.com/api/tablero/v1/casos?updated_since=2026-08-18T00:00:00Z&limit=100"

Reply to a case. Without en_nombre_de the reply signs as your team (author_type: agent); with en_nombre_de it signs as that end customer (author_type: client):

curl -X POST https://api.elportaldelcliente.com/api/tablero/v1/casos/$CASO_ID/respuestas \
  -H "Authorization: Bearer $TABLERO_KEY" \
  -H "Content-Type: application/json" \
  -d '{"body":"Ya lo revisamos: intente de nuevo.","autor_nombre":"Soporte Acme"}'

# ...or on behalf of the end customer:
  -d '{"body":"Sigue igual desde mi lado.","en_nombre_de":"cli-842"}'

Departments

Internal queues for your board (sales, billing, technical…). Each one can have its own IMAP mailbox: the board polls it and turns inbound email into cases.

The mailbox speaks IMAP, always (email_protocol: imap); the password is encrypted at rest and never returned. With email_polling_enabled: 1 polling runs automatically.

Access audit

Every access by our staff to your board's cases is recorded. This is the same audit as the “Provider access” tab, readable through the API:

curl -H "Authorization: Bearer $TABLERO_KEY" \
  https://api.elportaldelcliente.com/api/tablero/v1/accesos

Webhooks

Your system knows the moment it happens: every event arrives signed at your HTTPS URL.

Register as many as you need with POST /webhooks: an https URL, the events you want and a secret of at least 16 characters we will use to sign every delivery.

curl -X POST https://api.elportaldelcliente.com/api/tablero/v1/webhooks \
  -H "Authorization: Bearer $TABLERO_KEY" \
  -H "Content-Type: application/json" \
  -d '{"url":"https://su-sistema.com/hooks/tablero",
       "eventos":["caso.creado","caso.respondido","caso.estado_cambiado"],
       "secret":"un-secreto-de-al-menos-16-caracteres"}'

Each delivery is a POST with the event, the moment of emission and the minimum data needed to react. The signature covers timestamp.body:

POST /hooks/tablero
Content-Type: application/json
X-Tablero-Evento: caso.respondido
X-Tablero-Timestamp: 1765432100
X-Tablero-Firma: 3f1a…  # HMAC-SHA256(secret, timestamp + "." + body)

{"evento":"caso.respondido","emitido_at":"2026-08-18T20:15:00.000Z",
 "data":{"caso_id":"…","numero":"SOLC-1051","respuesta_id":"…","autor_tipo":"agent"}}

Verifying the signature

Reject any delivery whose signature does not verify or whose timestamp is more than 5 minutes off the clock. Compare in constant time.

// Node.js
const crypto = require('node:crypto');

function verificarFirma(rawBody, headers, secret) {
  const ts  = headers['x-tablero-timestamp'];
  const sig = headers['x-tablero-firma'];
  if (Math.abs(Date.now() / 1000 - Number(ts)) > 300) return false;
  const esperado = crypto.createHmac('sha256', secret)
    .update(ts + '.' + rawBody).digest('hex');
  return sig.length === esperado.length &&
    crypto.timingSafeEqual(Buffer.from(esperado), Buffer.from(sig));
}

# Python
import hashlib, hmac, time

def verificar_firma(raw_body: bytes, headers: dict, secret: str) -> bool:
    ts  = headers.get("x-tablero-timestamp", "")
    sig = headers.get("x-tablero-firma", "")
    if abs(time.time() - float(ts or 0)) > 300:
        return False
    esperado = hmac.new(secret.encode(), f"{ts}.".encode() + raw_body,
                        hashlib.sha256).hexdigest()
    return hmac.compare_digest(esperado, sig)

Delivery semantics (read this before you rely on it)

• One attempt per event, no retries. If your endpoint does not respond 2xx within 10 seconds, that delivery is lost — the real state can always be re-read through the API.
• Your safety net is incremental sync: a periodic pass of GET /casos?updated_since=… recovers any lost event.
• GET /webhooks shows each webhook's fail_count, last_ok_at and last_error_at: check them when debugging.
• Events are emitted no matter the channel: API, widgets, your team's panel, our staff or your end customer's inbound email.

Errors

JSON errors with success:false; the HTTP status code rules.

{"success":false,"error":"…"}

The error messages are human-readable text and may change. Branch your code on the HTTP status code and on these stable slugs:

Plans

Five annual plans, the same board. The difference is how many people and how much structure fit.

Current prices are published on the home page and through the public API (GET /api/public/tablero/plans). Every plan includes unlimited cases, widgets, API, webhooks and the access audit.

When your subscription expires there is a grace period; after that the board goes read-only (GETs keep responding, writes return 402). Your data is not deleted.

Operational limits

• Cases: unlimited on every plan. Listings accept a limit of 1 to 100 per page.
• End customers and audit: listings return up to 500 rows (most recent first). Use GET /clientes/:ref for point reads.
• Credentials: up to 5 active per board.
• Anonymous widgets: 10 attempts per visitor (IP) every 10 minutes.
• Attachments: the API does not accept files yet; inbound email attachments are kept with the case.

The trunk does not enforce a hard call quota today; operate at a reasonable pace (pauses between pages, retries with exponential backoff). If an integration needs guaranteed volume, let's talk first.