Workflows

Everything here uses one endpoint: POST /Documents/WRKCardSE. The difference between workflows is what you put in the request body, not the endpoint. If you haven't read Core Concepts yet, do that first — it explains check-in/check-out, reference dates, and the on-time window referenced below.

All examples assume you already have a valid accessToken — see Authentication.

Check-in

What you'll do

Record that an employee has arrived. Send one CardDetails entry with f_type: "0".

Request

curl -s -X POST \
  "https://trialv2eservices.yeka.gr/WebservicesAPI/Api/Documents/WRKCardSE" \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "Cards": {
      "Card": [
        {
          "f_afm_ergodoti": "094187530",
          "f_aa": "0",
          "f_comments": null,
          "Details": {
            "CardDetails": [
              {
                "f_afm": "028233026",
                "f_eponymo": "ΚΑΠΟΙΟΣ",
                "f_onoma": "ΛΑΜΠΡΟΣ",
                "f_type": "0",
                "f_reference_date": "2024-05-06",
                "f_date": "2024-05-06T08:55:00+03:00",
                "f_aitiologia": null
              }
            ]
          }
        }
      ]
    }
  }'

await fetch("https://trialv2eservices.yeka.gr/WebservicesAPI/Api/Documents/WRKCardSE", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${accessToken}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    Cards: {
      Card: [
        {
          f_afm_ergodoti: "094187530",
          f_aa: "0",
          f_comments: null,
          Details: {
            CardDetails: [
              {
                f_afm: "028233026",
                f_eponymo: "ΚΑΠΟΙΟΣ",
                f_onoma: "ΛΑΜΠΡΟΣ",
                f_type: "0",
                f_reference_date: "2024-05-06",
                f_date: "2024-05-06T08:55:00+03:00",
                f_aitiologia: null,
              },
            ],
          },
        },
      ],
    },
  }),
});

<?php
$payload = [
    "Cards" => ["Card" => [[
        "f_afm_ergodoti" => "094187530",
        "f_aa" => "0",
        "f_comments" => null,
        "Details" => ["CardDetails" => [[
            "f_afm" => "028233026",
            "f_eponymo" => "ΚΑΠΟΙΟΣ",
            "f_onoma" => "ΛΑΜΠΡΟΣ",
            "f_type" => "0",
            "f_reference_date" => "2024-05-06",
            "f_date" => "2024-05-06T08:55:00+03:00",
            "f_aitiologia" => null,
        ]]],
    ]]],
];

$ch = curl_init("https://trialv2eservices.yeka.gr/WebservicesAPI/Api/Documents/WRKCardSE");
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_POST, true);
curl_setopt($ch, CURLOPT_HTTPHEADER, [
    "Authorization: Bearer $accessToken",
    "Content-Type: application/json",
]);
curl_setopt($ch, CURLOPT_POSTFIELDS, json_encode($payload));
$result = json_decode(curl_exec($ch), true);
curl_close($ch);

Response

[{ "id": "101", "protocol": "ΕΥΣ101", "submitDate": "06/05/2024 08:55" }]

What went wrong

See Error Handling — the most common cause at this step is f_afm_ergodoti not matching the connected employer, or f_date being more than 15 minutes before the submission time (see Late and justified submissions).

Next step

Submit the matching check-out at end of day.

---

Check-out

What you'll do

Record that the same employee has left. Identical shape to check-in, with f_type: "1".

Request

Only the changed fields are shown — everything else is the same as check-in.

{
  "f_afm": "028233026",
  "f_eponymo": "ΚΑΠΟΙΟΣ",
  "f_onoma": "ΛΑΜΠΡΟΣ",
  "f_type": "1",
  "f_reference_date": "2024-05-06",
  "f_date": "2024-05-06T17:02:00+03:00",
  "f_aitiologia": null
}

Send this CardDetails entry inside the same Cards.Card[].Details envelope as check-in, with your real f_afm_ergodoti and f_aa.

Response

[{ "id": "104", "protocol": "ΕΥΣ104", "submitDate": "06/05/2024 17:02" }]

What went wrong

A check-out is rejected if f_reference_date doesn't match an existing check-in for that employee, or if the date/time rules in Work Card API Reference aren't met (e.g. a night-shift check-out after 11:00 the next day).

Next step

If the employee left and came back (split shift), see Bulk submissions and Split shifts. If you submitted the wrong time, see Corrections.

---

Corrections

What you'll do

Fix a check-in or check-out you already submitted — without an edit or delete endpoint. Submit a new event of the same type, for the same employee and f_reference_date, with the corrected f_date.

Ergani always treats the most recently submitted event of a given f_type for a given f_afm + f_reference_date as authoritative. Your correction replaces the earlier value; the earlier submission is not deleted, just superseded.

Request

Example: you submitted a check-in at 08:55 but the employee actually arrived at 08:47. Resubmit:

{
  "f_afm": "028233026",
  "f_eponymo": "ΚΑΠΟΙΟΣ",
  "f_onoma": "ΛΑΜΠΡΟΣ",
  "f_type": "0",
  "f_reference_date": "2024-05-06",
  "f_date": "2024-05-06T08:47:00+03:00",
  "f_aitiologia": null
}

Response

[{ "id": "102", "protocol": "ΕΥΣ102", "submitDate": "06/05/2024 09:10" }]

A new protocol — this is a separate, successful submission. The Actual Work Calendar will now show 08:47 as the check-in time for that day.

Submitting this late?

If you're correcting a check-in from earlier in the day, more than 15 minutes will likely have passed since f_date. That makes this submission late — see Late and justified submissions. Most corrections of past events cannot use a justification code (codes 001–003 are for force-majeure only) — see Late correction for how to handle this honestly.

What went wrong

Same as check-in/check-out — see Error Handling.

Next step

If this correction is itself outside the 15-minute window, read Late and justified submissions before you submit.

---

Late and justified submissions

What you'll do

Submit an event more than 15 minutes after it happened, with a justification code, when (and only when) the delay was caused by one of three force-majeure situations.

Justification codes are not a general "late" excuse

f_aitiologia codes 001–003 cover power/telecom outages, employer system failures, and Ergani connectivity problems — situations outside your control. They do not cover "we forgot," "the device was off," or "we batch-upload once a day." If your delay doesn't match one of the three codes, see Employee forgets to check out for the honest answer.

Request

{
  "f_afm": "028233026",
  "f_eponymo": "ΚΑΠΟΙΟΣ",
  "f_onoma": "ΛΑΜΠΡΟΣ",
  "f_type": "1",
  "f_reference_date": "2024-05-06",
  "f_date": "2024-05-06T17:02:00+03:00",
  "f_aitiologia": "003"
}

f_aitiologia	Use when
"001"	Power or telecom outage prevented submission.
"002"	A failure in your own systems prevented submission.
"003"	Your system couldn't reach Ergani.

Response

[{ "id": "105", "protocol": "ΕΥΣ105", "submitDate": "06/05/2024 18:30" }]

The event is recorded as late (Εμπρόθεσμη: Όχι) but accepted.

What went wrong

f_aitiologia rejected → the value isn't one of "001", "002", "003", or null.

Next step

Per Άρθρο 2 της Υ.Α. 49758/31.05.2022, if you used a justification code, you must also have notified the competent Labour Inspectorate (Επιθεώρηση Εργασίας) about the outage when it started and when it ended — this is a legal obligation separate from the API call.

---

Bulk submissions

What you'll do

Submit multiple check-in/check-out events in one request — multiple employees, multiple branches, or both.

Multiple employees, same branch

Add more entries to CardDetails:

{
  "Cards": {
    "Card": [
      {
        "f_afm_ergodoti": "094187530",
        "f_aa": "0",
        "f_comments": null,
        "Details": {
          "CardDetails": [
            {
              "f_afm": "028233026",
              "f_eponymo": "ΚΑΠΟΙΟΣ",
              "f_onoma": "ΛΑΜΠΡΟΣ",
              "f_type": "0",
              "f_reference_date": "2024-05-06",
              "f_date": "2024-05-06T08:55:00+03:00",
              "f_aitiologia": null
            },
            {
              "f_afm": "017453982",
              "f_eponymo": "ΠΑΠΑΔΟΠΟΥΛΟΥ",
              "f_onoma": "ΕΛΕΝΗ",
              "f_type": "0",
              "f_reference_date": "2024-05-06",
              "f_date": "2024-05-06T08:59:00+03:00",
              "f_aitiologia": null
            }
          ]
        }
      }
    ]
  }
}

Multiple branches

Add more entries to Cards.Card, each with its own f_aa and CardDetails:

{
  "Cards": {
    "Card": [
      {
        "f_afm_ergodoti": "094187530",
        "f_aa": "0",
        "f_comments": null,
        "Details": { "CardDetails": [ /* branch 0 events */ ] }
      },
      {
        "f_afm_ergodoti": "094187530",
        "f_aa": "1",
        "f_comments": null,
        "Details": { "CardDetails": [ /* branch 1 events */ ] }
      }
    ]
  }
}

Response

One response entry per submitted event, in the same order:

[
  { "id": "106", "protocol": "ΕΥΣ106", "submitDate": "06/05/2024 09:00" },
  { "id": "107", "protocol": "ΕΥΣ107", "submitDate": "06/05/2024 09:00" }
]

What went wrong

A 400 Bad Request for one invalid event in the batch rejects the whole request — there is no partial success. Validate every event client-side before sending (see Glossary and Work Card API Reference for field rules).

Next step

Read Production Guide for batching, logging, and retry strategy before sending bulk requests in production.