Send subject requests from your backend

Your users already prove who they are when they sign in to your app. This guide adds a "my data" request to your app: your server checks the user is signed in, then sends the request to Izini's DSAR gateway, which opens a case for your DPO with a reference number you can show the user.

You need: a project, a server-side route behind your own sign-in, and an API key.

In the dashboard, open Developers > API keys (also under DSAR > Integration > Authentication) and create a test key with the dsar:write scope (organisation admins and owners can, and so can a team member with the Privacy Engineer / IT Lead role). It starts with iz_dsar_test_. Cases it creates are marked as tests (DSR-TEST-…), so you can build and try the whole flow before going live.

Keep the key on your server, in an environment variable such as IZINI_API_KEY. Never put it in an app or a web page.

Add a route that only signed-in users can reach. It sends Izini your own id for the user, never their email address or phone number, and says how you verified them.

// An Express route behind your own sign-in middleware.
app.post('/privacy/requests', requireSignedIn, async (req, res) => {
  const response = await fetch('https://app.izini.ng/api/v1/gateway/dsar', {
    method: 'POST',
    headers: {
      Authorization: `Bearer ${process.env.IZINI_API_KEY}`,
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({
      customer_id: req.user.id,               // your id for the user
      request_type: req.body.requestType,      // e.g. 'access' or 'erasure'
      verification: {
        verified: true,
        method: 'password_session',            // how the user proved who they are
        verified_at: req.user.signedInAt,      // when, as an ISO 8601 time
        verified_by: 'acme-web',               // which of your systems checked
      },
      details: {
        external_reference: req.body.ticketId, // optional: your own case or ticket number
        locale: req.user.locale,
      },
    }),
  });

  const data = await response.json();
  if (!response.ok) {
    // data.message says what went wrong; see "Handle the answers" below.
    return res.status(502).json({ message: 'Your request could not be sent. Please try again.' });
  }
  res.json({ reference: data.reference_number });
});

Show the user reference_number (for example DSR-2026-K7QX). Your DPO sees the same reference on the case in Izini.

request_type	The user asks to
access	see the personal data you hold about them
copy_portability	get a copy in a format they can take elsewhere
rectification	correct data that is wrong
erasure	have their data deleted
restriction	have you stop using their data for now
objection	object to how you use their data
consent_withdrawal	withdraw a consent they gave
marketing_opt_out	stop receiving marketing
automated_decision	have a person review a decision made automatically

Erasure, rectification and access each have their own workflow in Izini; the other rights run on the access workflow and keep their own name on the case. download, delete_data and access_data are also accepted, for older integrations.

Keep the details of a correction (the new address, say) in your own system. Izini records that a correction was asked for, not the personal data itself.

Status	Meaning	What to do
201	The case is open.	Show the user reference_number.
400	A field is missing or invalid, or customer_id looks like an email, phone or card number.	Fix the request; message says which field.
401 / 403	The key is missing, unknown or revoked.	Check IZINI_API_KEY.
422	verification.verified was not true.	Only send requests for users you have verified.
429	More than 120 requests a minute with this key.	Wait and retry.
500	A problem on Izini's side.	Retry later; quote ref to support.

A 201 can carry warnings, for example when customer_id is 11 digits like a NIN. The request still went through; send an internal id next time.

1. Send a request with the test key. The case appears in Subject Rights (DSAR) with a DSR-TEST- reference.
2. Walk through the checklist under DSAR > Integration.
3. Create a live key (iz_dsar_live_…), put it in your production settings, and revoke the test key if you no longer need it.

• Izini never sees the person's contact details through this route. If your DPO needs to reach them, they do it through your own systems, using your id.
• The status of a case is in the DSAR desk in the dashboard. Webhooks for case events (received, due soon, closed) are planned.

The full request and response are in the API reference.