Kalo te dokumentacioni
API

Jepni dhe revokoni një adresë

Boshti i dytë: cilat adresa mund të prekë një person dhe në ç’nivel.

POSTapi.openemail.uk/members/{userId}/addresses

Ekzekuton cilëndo nga 2 thirrjet e kësaj faqeje kundrejt hapësirës suaj të punës, me çelësin tuaj.

POST /members/{userId}/addresses

Boshti i dytë: cilat adresa mund të prekë një person dhe në ç’nivel.

Një e drejtë nuk është rol

access është fjalori i vjetër për adresa të veçanta dhe qëllimisht nuk mbivendoset me emrat e lejeve: member e lexon adresën dhe dërgon si ajo, viewer vetëm e lexon. Ai nuk thotë asgjë për faktin nëse personi mund të dërgojë fare — kjo është puna e rolit të tij — dhe që të dyja duhet ta lejojnë dërgimin para se ai të ndodhë.

Roli i tijE drejta e tij mbi billing@A mund të dërgojë si billing@
e mban `emails:send`memberPo.
e mban `emails:send`viewerJo, e drejta e refuzon.
pa `emails:send`memberJo, roli e refuzon.
e mban `emails:send`asnjë e drejtë fareJo, adresa nuk hyn kurrë te lista ndaj së cilës kontrollohet një dërgim.

Dhënia e një roli dikujt nuk i jep asnjë adresë. Një anëtar me një rol dhe pa asnjë të drejtë hap një kuti postare BOSH e jo kutinë e të gjithëve, që është dështimi i duhur derisa po vendosni ende çfarë duhet të shohë.

Jepni një adresë

Kërkon members:write. POST /members/{userId}/addresses me { addressId, access }; access si parazgjedhje është member. Kthen të gjithë anëtarin ashtu siç është tani.

curl
curl -X POST "$OE/members/nQ8vBz1aRd4tYwKx7fQ2mN8vBz1aRd4t/addresses" -H "$AUTH" \    -H "Content-Type: application/json" \    -d '{ "addressId": "c40a95f2-1cc6-4d31-82a8-9e075d31c2a8", "access": "viewer" }'
Përgjigje
{    "object": "member",    "userId": "nQ8vBz1aRd4tYwKx7fQ2mN8vBz1aRd4t",    "email": "[email protected]",    "name": "Sam Okonjo",    "image": null,    "role": {      "id": "role_2b81de079c1f0a4b7e05d386",      "name": "Support",      "builtin": null    },    "implied": false,    "permissions": ["emails:send", "emails:read", "threads:read", "threads:write"],    "addresses": [      {        "addressId": "2b81de07-9c1f-4a4b-8e05-d3862c1f0a44",        "address": "[email protected]",        "access": "member"      },      {        "addressId": "c40a95f2-1cc6-4d31-82a8-9e075d31c2a8",        "address": "[email protected]",        "access": "viewer"      }    ],    "createdAt": "2026-08-12T14:20:00.000Z"  }

POST mbi nënkoleksionin e jo një PUT mbi çiftin, sepse është një upsert sidoqoftë dhe id-ja e rreshtit nuk është diçka që e emërton ndonjëherë një thirrës. Ripostimi me një access tjetër është mënyra si një viewer bëhet member: ka një rresht të vetëm për secilin çift (adresë, person), ndaj një thirrje e dytë e ndryshon nivelin në vend që të shtojë një të drejtë të dytë. Kjo e bën gjithashtu këtë POST të rrallë që është i sigurt të përsëritet.

I kushtëzuar nga members:write e jo nga zotërimi i adresës, dhe këtu qëndron ndryshimi mes kësaj dhe rrugës së vjetër të dhënies te routeri i domeneve. Zotërimi është kushti i duhur për personin që e futi domenin dhe i gabuar për një administrator që nuk zotëron asgjë dhe po drejton qasjen e hapësirës së punës në emër të pronarit. Që të dyja shkruajnë të njëjtin rresht.

Kthehet i gjithë anëtari e jo vetëm e drejta, që rreshti në ekran të mund të rirenderohet pa një kërkesë të dytë dhe që përgjigjja të lexohet njësoj pavarësisht nëse e drejta ishte e re apo një ndryshim.

Një adresë që nuk i përket kësaj hapësire pune është member_not_found, një 422, që mbart param: "addressId". Një çelës mund të japë vetëm adresa që i përkasin hapësirës së punës për të cilën u lëshua.

Dhënia e një të drejte PRONARIT të hapësirës së punës është member_is_owner, një 422. Ai i ka tashmë të gjitha adresat e saj, ndaj nuk ka asgjë që thirrja të shtonte.

Revokoni një adresë

Kërkon members:write. DELETE /members/{userId}/addresses/{addressId}. Kthen anëtarin, pa atë adresë.

curl
curl -X DELETE \    "$OE/members/nQ8vBz1aRd4tYwKx7fQ2mN8vBz1aRd4t/addresses/c40a95f2-1cc6-4d31-82a8-9e075d31c2a8" \    -H "$AUTH"
Përgjigje
{    "object": "member",    "userId": "nQ8vBz1aRd4tYwKx7fQ2mN8vBz1aRd4t",    "email": "[email protected]",    "name": "Sam Okonjo",    "image": null,    "role": {      "id": "role_2b81de079c1f0a4b7e05d386",      "name": "Support",      "builtin": null    },    "implied": false,    "permissions": ["emails:send", "emails:read", "threads:read", "threads:write"],    "addresses": [      {        "addressId": "2b81de07-9c1f-4a4b-8e05-d3862c1f0a44",        "address": "[email protected]",        "access": "member"      }    ],    "createdAt": "2026-08-12T14:20:00.000Z"  }

Revokimi i ngushtë, dhe ai që duhet përdorur kur dikush ndërron ekip: ai mban rolin dhe adresat e tjera dhe pushon së pari këtë.

Një adresë që nuk i përket kësaj hapësire pune refuzohet në vend që të shpërfillet në heshtje. Përndryshe një gabim shtypi te id-ja do të raportonte një revokim të suksesshëm që nuk ndodhi kurrë — pikërisht dështimi për të cilin ekziston ky endpoint.

Kthehet anëtari e jo një gur varri, sepse përgjigjja interesante është çfarë mund të prekë ende. Një { deleted: true } këtu do ta linte klientin ta nxirrte këtë me zbritje.

Për t’i hequr të gjitha njëherësh, DELETE /members/{userId} heq rolin dhe çdo të drejtë bashkë dhe raporton sa u hoqën.