> ## Documentation Index > Fetch the complete documentation index at: https://orgo.space/docs/llms.txt > Use this file to discover all available pages before exploring further. # Remove assignee from a task > Removes a user assignment from a task. Requires PROJECT_EDIT permission on the parent project. ## OpenAPI ````yaml /api-reference/openapi.json delete /api/v1/task_assignees/{uuid} openapi: 3.1.0 info: title: Orgo API description: > The Orgo API is a REST/JSON-LD API for managing the full lifecycle of a member-driven organization: people (members, contacts, families, companies), events and tickets, payments and invoices, contracts and e-signatures, communications (newsletters, discussions, notifications), governance (voting, org charts), and learning (courses, badges). It is built on Symfony 7 and API Platform 3.4. Every resource follows the same conventions — pagination, filtering, ordering, content negotiation, validation, tenant isolation — so once you know one endpoint, you know the shape of all of them. ## Base URL ``` https://app.orgo.space ``` All endpoints are prefixed with `/api/v1/`. For example: `GET https://app.orgo.space/api/v1/users`. ## Authentication The API accepts five authentication methods. Pick by use case: | Method | When to use | How | |---|---|---| | `Api-Token` header | Server-to-server integrations, scripts, CRON jobs | `Api-Token: ` (no `Bearer` prefix) | | `Authorization: Bearer ` | Sessions started via `POST /api/v1/login` (email + password) | Standard Bearer JWT | | OAuth 2.0 (Authorization Code) | "Log in with Orgo" in third-party apps | See [OAuth Server](https://orgo.space/docs/platform/oauth) | | OTP (one-time password) | Magic-link login for event attendees and members without a password | `POST /api/v1/request-login-otp` → `POST /api/v1/verify-login-otp` | | `X-Contact-Hash` header | Anonymous contacts opening an event link they were emailed | `X-Contact-Hash: ` | Tokens issued by `/api/v1/login` and `/api/v1/verify-login-otp` are JWTs valid for approximately 11 days. Generate API tokens in the admin UI at **Settings → Developers → API Access**. Read-only tokens reject any non-GET request with `403 Forbidden`. ## Tenant context Orgo is multi-tenant. Each organization (a "tenant") has its own subdomain or custom domain. The tenant for a request is resolved from the HTTP `Host` header — calling `app.orgo.space` directly **will not work** for tenant-scoped endpoints. You must call your tenant's host: ``` https://.orgo.space/api/v1/users https://members.your-domain.org/api/v1/users ``` Every read and write is automatically scoped to the tenant the request was made against. Cross-tenant reads are blocked at the persistence layer by Doctrine extensions, so even a misconfigured query cannot leak data across organizations. ## Content negotiation Most endpoints support three response formats. Select with the `Accept` header: | Accept | Format | When to use | |---|---|---| | `application/ld+json` (default) | JSON-LD with Hydra | Browsing, link discovery, generic clients | | `application/json` | Plain JSON | Most integrations — simpler shape, no `@context`/`@id` | | `multipart/form-data` | Multipart | Only on endpoints that accept file uploads | For request bodies, use `Content-Type: application/json` for create/replace and `Content-Type: application/merge-patch+json` for PATCH (RFC 7396). ## Collection responses (Hydra envelope) `Accept: application/ld+json` (the default) wraps collections in a Hydra envelope: ```json { "@context": "/api/contexts/User", "@id": "/api/v1/users", "@type": "hydra:Collection", "hydra:member": [ { ... }, { ... } ], "hydra:totalItems": 1248, "hydra:view": { "@id": "/api/v1/users?page=1", "@type": "hydra:PartialCollectionView", "hydra:first": "/api/v1/users?page=1", "hydra:last": "/api/v1/users?page=42", "hydra:next": "/api/v1/users?page=2" } } ``` `Accept: application/json` returns a bare array — no envelope, no total count, no pagination links. Use JSON-LD if you need totals or page navigation; use plain JSON if you already know the shape. ## Pagination All collection endpoints are paginated. Defaults: **30 items per page**, maximum **100 per page**. | Query parameter | Purpose | Default | |---|---|---| | `page` | 1-indexed page number | `1` | | `itemsPerPage` | Page size (max 100) | `30` | | `pagination` | Set to `false` to disable pagination (where allowed) | `true` | Iterate pages by following `hydra:view.hydra:next` until it is absent, or by incrementing `page` until you receive fewer than `itemsPerPage` items. ## Filtering and ordering Filters and ordering are passed as query parameters. The available filters differ per resource and are listed under each endpoint's parameters. Common patterns: ``` # Filter by exact value GET /api/v1/users?status=ACTIVE # Filter by relation GET /api/v1/users?localCenter=/api/v1/local_centers/4 # Keyword search (where supported) GET /api/v1/users?keyword=patterson # Ordering — ascending GET /api/v1/users?order[lastName]=asc # Ordering — multiple fields GET /api/v1/events?order[startDate]=desc&order[name]=asc ``` ## Errors Errors are returned as JSON with `Content-Type: application/json` and a status code that reflects the error class. The shape is: ```json { "title": "Bad Request", "detail": "Email must be a valid email address.", "status": 400 } ``` Validation errors (`422`) include a `violations` array enumerating each failed field: ```json { "@type": "ConstraintViolationList", "title": "An error occurred", "detail": "email: This value is not a valid email address.\nphoneNumber: This value is too short.", "violations": [ { "propertyPath": "email", "message": "This value is not a valid email address." }, { "propertyPath": "phoneNumber", "message": "This value is too short." } ] } ``` | Status | Meaning | When to retry | |---|---|---| | `400 Bad Request` | Malformed request — JSON syntax, wrong content type, missing parameter | No — fix the request | | `401 Unauthorized` | Missing or invalid auth | After re-authenticating | | `403 Forbidden` | Authenticated, but lacks permission for this resource | No | | `404 Not Found` | Resource does not exist or is in another tenant | No | | `409 Conflict` | Optimistic-lock collision, duplicate identifier, illegal state transition | Yes — refetch and retry | | `422 Unprocessable Entity` | Validation failed | No — fix the fields listed in `violations[]` | | `429 Too Many Requests` | Rate limit hit on this endpoint | After the `Retry-After` window | | `5xx` | Server error | Yes, with exponential backoff | See [Errors](https://orgo.space/docs/api-reference/concepts/errors) for the full error catalog and worked examples. ## Rate limits Rate limits are applied per-endpoint, per-token. Most write-heavy endpoints (login, OTP requests, impersonation, sending emails) are limited to **20 requests per 60 seconds**. Read endpoints are not rate-limited at the application layer but are subject to platform-level protections. A `429 Too Many Requests` response carries the standard `Retry-After` header. ## Webhooks Orgo can deliver event notifications to a URL of your choosing — see [Webhooks](https://orgo.space/docs/api-reference/concepts/webhooks). Eighteen event types are available across users, payments, event attendance, contracts, roles, and contacts. ## Versioning and stability The API is versioned in the URL path (`/api/v1/`). Additive changes (new fields, new endpoints, new optional parameters) ship in `v1`. Breaking changes (removed fields, renamed properties, status-code changes) will ship in a future `/api/v2/` with at least six months of overlap. ## Pointers - [Authentication](https://orgo.space/docs/api-reference/concepts/authentication) — every auth method, with worked examples - [Tenancy](https://orgo.space/docs/api-reference/concepts/tenancy) — how tenant resolution works and how to scope requests - [Content types](https://orgo.space/docs/api-reference/concepts/content-types) — JSON-LD vs JSON vs multipart, when to pick which - [Pagination and filters](https://orgo.space/docs/api-reference/concepts/pagination-and-filters) — exhaustive filter reference - [Errors](https://orgo.space/docs/api-reference/concepts/errors) — every error shape and when to expect it - [Rate limits](https://orgo.space/docs/api-reference/concepts/rate-limits) — the per-endpoint table - [Webhooks](https://orgo.space/docs/api-reference/concepts/webhooks) — events, payloads, signature verification - [Recipes](https://orgo.space/docs/api-reference/recipes) — end-to-end walkthroughs ("Onboard a new member", "Sell event tickets", ...) version: 1.0.0 contact: name: Orgo Support url: https://orgo.space/docs/api-reference email: support@orgo.space termsOfService: https://orgo.space/terms license: name: Proprietary url: https://orgo.space/terms x-orgo-postprocessed: '2026-07-25T14:53:15+00:00' servers: - url: https://app.orgo.space description: >- Production — replace with your tenant subdomain or custom domain for tenant-scoped calls (e.g. https://your-org.orgo.space). security: - ApiToken: [] - JWT: [] tags: - name: DashboardWelcomeMessage description: |- A configurable banner / message that appears at the top of the member dashboard — used for announcements, onboarding tips, or seasonal campaigns. Tenant-scoped, can be targeted per user via the current_user endpoint. - name: EventStatus description: Resource 'EventStatus' operations. - name: FormSubmission description: Resource 'FormSubmission' operations. - name: FormSubmissionAnswer description: Resource 'FormSubmissionAnswer' operations. - name: TenantProfessionDisabled description: Resource 'TenantProfessionDisabled' operations. - name: UserOption description: Resource 'UserOption' operations. - name: Adhesion description: |- A membership application. The applicant fills in personal data, uploads an ID document and a signed adhesion form, optionally records a video answer, and submits it for HR review. HR runs an interview, then transitions the application to a final state — which in turn assigns the `MEMBER` role and activates the fee. Lifecycle: `NEW` (draft, editable) → `PENDING` (submitted) → `VALIDATED` (data verified) → `INTERVIEWED` (interview complete) → `SUCCESS` (member activated) or `REJECTED` (terminal). Each transition can trigger emails (confirmation, rejection, welcome) and side effects (role assignment, fee start). - name: Badge description: Resource 'Badge' operations. - name: BadgeType description: Resource 'BadgeType' operations. - name: BadgeUser description: Resource 'BadgeUser' operations. - name: BadgeHour description: Resource 'BadgeHour' operations. - name: BundleMember description: Resource 'BundleMember' operations. - name: Certification description: Resource 'Certification' operations. - name: Company description: >- An organizational member — a business, partner organization, or sponsor that pays membership separately from individual users. Companies have their own invitations, members (users with company roles), invoices, payment plans, and bank-transfer flows. Lifecycle: `NEW` → `ACTIVE` → `DELETED` (soft, when the last member leaves). Most company operations require `COMPANY_*` permissions that the primary contact or tenant admin holds. - name: CompanyInvitation description: Resource 'CompanyInvitation' operations. - name: CompanyUser description: Resource 'CompanyUser' operations. - name: Contact description: >- A person tracked by the organization who does not have a member account — prospects, event attendees, newsletter subscribers, donors. Contacts share most profile fields with Users (email, phone, custom fields) but cannot log in. A Contact can be converted into a User by initiating an adhesion or sending an invitation. Contacts are scoped to a local center and protected by the same tenant-isolation rules as Users. - name: Contract description: |- A reusable contract template — membership agreement, NDA, code of conduct, parental-consent form. Defines the content, placeholder fields (resolved per-signer from User profile and custom fields), signature requirements (member-only, admin co-sign, default-admin-signature), and which units the contract applies to. Editing a contract can invalidate existing signatures via the request-resigning endpoint. - name: ContractUser description: >- An individual instance of a Contract assigned to a specific User or Contact. Holds signature status, the rendered placeholder values, the signed PDF, and validity dates. Lifecycle: `UNSIGNED` → `SIGNED` (with or without digital signature) → optionally `EXPIRED`. Admins can mark contracts as signed manually or apply a default-admin signature in bulk. - name: Country description: Resource 'Country' operations. - name: County description: Resource 'County' operations. - name: Course description: Resource 'Course' operations. - name: CourseEnrollment description: |- A User's enrollment in a Course — including progress through lessons, quiz scores, and completion status. Created when a user self-enrolls or when an admin enrolls them (with optional notification). Exporting enrollments produces a CSV for reporting. - name: CourseLesson description: |- A unit of course content — text, video, downloadable media. Lessons are ordered within a Course and surfaced sequentially to the enrolled User. Media attachments use the standard Media + S3 storage. - name: CourseLessonAttachment description: Resource 'CourseLessonAttachment' operations. - name: CourseQuiz description: |- An assessment attached to a Course — multiple-choice questions with a pass/fail threshold. Quiz results are recorded per CourseEnrollment and can be exported for the course administrator. - name: CourseSection description: Resource 'CourseSection' operations. - name: CustomField description: Resource 'CustomField' operations. - name: CustomFieldValue description: > Stored answers for tenant-defined custom fields. Each row links a CustomField definition to one of three possible owners: a user (`user`), a contact (`contact`), or an event attendance (`eventAttend`). Exactly one of these is set per row; the others are null. The `value` column holds the answer as a string (multi-option fields store a comma-separated list, file/image fields store the answer in `media` and leave `value` blank). All queries are tenant-isolated through `field.tenant`, which is guaranteed non-null. The endpoint exposes only the values whose custom field definition belongs to the current user's tenant. Custom field values attached to event attendances are typically read through `/event_attends/{id}` rather than this collection. Values can be created directly through `POST` on this resource (one value per request, with exactly one of `user`/`contact`/ `eventAttend` set), or as nested writes inside the owning entity (e.g. `PATCH /users/{id}` with a `rawUserCustomFieldsValues` map, `PATCH /contacts/{id}` with `rawContactCustomFieldsValues`). The direct `POST` route delegates to the same underlying service as the nested-write path, so encryption, file-media handling, and field-visibility checks behave identically. - name: DashboardCategory description: Resource 'DashboardCategory' operations. - name: DashboardWidget description: Resource 'DashboardWidget' operations. - name: Discussion description: |- A thread of conversation within a DiscussionNamespace. Owned by a Unit (group, local center, project), visible per the unit's privacy rules. Reuses Post entities for the actual messages. - name: DiscussionNamespace description: |- A category that groups discussions — for example "Announcements", "General", "Volunteers". Each namespace has its own permission model and surfaces the latest discussion via a dedicated endpoint. - name: TopicType description: Resource 'TopicType' operations. - name: Drive description: |- A shared folder / file storage namespace — like a Google Drive folder scoped to a Unit or User. Supports browsing, search ("latest" and full- text), and sharing/revoking access. Each Drive entry is either a folder or a file; files are stored in S3. - name: EducationIndustry description: Resource 'EducationIndustry' operations. - name: EmailTemplate description: |- A customizable transactional email — registration confirmation, payment receipt, contract-signing reminder, etc. Templates ship with default content per tenant; admins can override the subject, body, and locale. Send-test and preview endpoints help verify changes before they go live. - name: Event description: |- A scheduled gathering — meeting, conference, workshop, social, vote assembly. Owns its public landing page, ticket types, registration form, attendees, capacity rules, and post-event reports. Lifecycle: `DRAFT` (visible only to organizers) → `PUBLISHED` (visible per audience rules) → effectively closed once the start date passes. Events can be duplicated, saved as templates, and chained into series (sub-events). - name: EventType description: Resource 'EventType' operations. - name: EventMedia description: Resource 'EventMedia' operations. - name: EventAttend description: |- A registration record linking a User or Contact to an Event. Carries the registration form answers, ticket type, payment status, guest tickets, check-in state, and any QR-code identifier. Lifecycle: `NEW` (registered) → `CONFIRMED` (admin-approved if required) → checked-in at the door. External invites (for non-Users) generate Contact records on confirmation. - name: EventSpeaker description: Resource 'EventSpeaker' operations. - name: EventTemplate description: |- A saved event blueprint used to spin up similar events quickly — recurring weekly meetings, annual fundraisers, standard workshop formats. Stores the same fields as Event minus the date. The create-from-template endpoint clones it into a new draft Event ready for date editing. - name: EventVoucher description: Resource 'EventVoucher' operations. - name: ExperienceHistory description: Resource 'ExperienceHistory' operations. - name: FamilyEntity description: |- A household grouping that links related Users — typically a parent account with linked children or a couple sharing a single membership. Family membership can affect fees (e.g., one fee covers the whole household) and determines whose data a guardian account can edit. Created by the family primary, joined via invitation. Has its own delete endpoint distinct from the standard DELETE (preserves member accounts). - name: FamilyMember description: Resource 'FamilyMember' operations. - name: FeePayment description: >- A simplified, hand-recorded fee receipt — the cash-and-paper alternative to the full ProductPayment + Invoice flow. Used mostly by treasurers entering payments collected outside Orgo. Carries an approval endpoint for the reviewer workflow. - name: Form description: |- A custom form — registration form, survey, intake questionnaire, event RSVP form. Renders a public page that anyone with the link can fill in; submissions become FormSubmission records. Forms can resolve a "slug-go" short link, recalculate statistics, and export submissions as a table. - name: FormField description: Resource 'FormField' operations. - name: Goal description: Resource 'Goal' operations. - name: Group description: Resource 'Group' operations. - name: GroupCategory description: Resource 'GroupCategory' operations. - name: Identity description: >- An identity-verification record on a User or anonymous applicant — the government ID document, OCR-extracted personal data, and validation status. Created either during an adhesion (upload-id step) or by an admin marking someone as verified. Lifecycle: `PENDING` → `VALIDATED` (admin-approved) or `REJECTED`. Reopening is possible. See [Identity Validation](https://orgo.space/docs/platform/identity-validation). - name: Invoice description: |- A formal billing document issued for one or more ProductPayments — usually for bank-transfer flows, company memberships, or any payment that needs a PDF record for accounting. Lifecycle: `PENDING` → `PAID` / `VOID`. Carries cancel, mark-as-paid, refund, void, send-email, and download endpoints. - name: InvoiceTemplate description: Resource 'InvoiceTemplate' operations. - name: IssueStatus description: Resource 'IssueStatus' operations. - name: IssueType description: Resource 'IssueType' operations. - name: LocalCenter description: >- A geographic or operational chapter of the organization — a city branch, a university campus, a regional office. Local centers carry their own admins, fees, members, events, and contracts. Most permission scopes (`HR_LOCAL`, `FINANCIAL_LOCAL`, `ADMIN_LOCAL`) are bounded to a specific local center. Has a public listing endpoint and a map endpoint for the public-facing "find your local center" page. - name: LocalCenterRequest description: Resource 'LocalCenterRequest' operations. - name: LocalCenterUserPreference description: Resource 'LocalCenterUserPreference' operations. - name: LocalCenterUserType description: Resource 'LocalCenterUserType' operations. - name: Newsletter description: >- An email campaign — composed in the drag-and-drop builder, segmented by audience filter, scheduled or sent immediately, and tracked for opens / clicks. Lifecycle: `DRAFT` → `SCHEDULED` or `SENT`. Has clone, clone-to-non- openers, and audience-statistics endpoints. Public preview pages let recipients view the email in a browser. - name: NewsletterTemplate description: Resource 'NewsletterTemplate' operations. - name: Objective description: Resource 'Objective' operations. - name: OfficialGazette description: Resource 'OfficialGazette' operations. - name: OfficialGazetteType description: Resource 'OfficialGazetteType' operations. - name: Post description: >- A message in a Discussion thread — top-level posts, replies, reactions, and moderation actions. Posts can be reported, removed, or moderated by users with the right permission. Reactions are tallied per post and exposed via a dedicated endpoint. - name: Product description: >- Anything you can sell or collect money for — membership fees, event tickets, merchandise, course enrollment fees, donations. Each Product has one or more ProductPrices (defining amount, currency, billing period) and a public payment page. Lifecycle: `DRAFT` → `PUBLISHED` (live and purchasable) → `ARCHIVED` (hidden from listings, existing payments preserved). Requires `FINANCIAL_LOCAL` or `FINANCIAL_TENANT` to manage. - name: ProductOption description: Resource 'ProductOption' operations. - name: ProductPayment description: |- A single payment instance against a Product — one ticket purchase, one membership-fee period, one donation, one bundle slot. Created by Stripe checkout, manual entry, bank transfer, or bundle membership. Lifecycle: `PENDING` (awaiting capture) → `SUCCESS` (paid) or `REJECTED` / `CANCELED`. Refunds, comment annotations, and proof uploads each have dedicated endpoints. - name: ProductPrice description: Resource 'ProductPrice' operations. - name: ProductPriceAddon description: Resource 'ProductPriceAddon' operations. - name: ProfessionType description: >- A profession/industry classification used on User and Contact profiles for segmentation and reporting (e.g., "Engineering", "Healthcare", "Education"). Tenant-scoped; admins can enable or disable specific values for their org through bulk-toggle endpoints. - name: ProfessionJob description: Resource 'ProfessionJob' operations. - name: ProfileStatus description: Resource 'ProfileStatus' operations. - name: ProfileTag description: >- A free-form label that admins attach to Users or Contacts for segmentation — for example "donor 2026", "speaker", "vegetarian". Tags are tenant-scoped and reusable. Used heavily by Newsletter audience filters and event-invite segments. - name: Project description: |- A team workspace — a working group, a campaign, a one-off initiative. Owns its members, tasks, drive folder, and discussion namespace. Lifecycle is open-ended — projects stay around until explicitly deleted. - name: QuizAnswer description: Resource 'QuizAnswer' operations. - name: QuizAttempt description: Resource 'QuizAttempt' operations. - name: QuizQuestion description: Resource 'QuizQuestion' operations. - name: Referral description: Resource 'Referral' operations. - name: ReferralUser description: Resource 'ReferralUser' operations. - name: Region description: Resource 'Region' operations. - name: ResignationRequest description: Resource 'ResignationRequest' operations. - name: Role description: Resource 'Role' operations. - name: RoleGroup description: Resource 'RoleGroup' operations. - name: SubscriptionProfile description: |- A recurring billing relationship — typically a member's annual membership fee or a company's quarterly invoice. Captures the price, the period, the next due date, and the payment method. Admins can pre-create pending subscriptions and accept them once payment clears. External subscription profiles cover Stripe Billing subscriptions managed outside Orgo. - name: SupportTeam description: Resource 'SupportTeam' operations. - name: Tag description: Resource 'Tag' operations. - name: Task description: |- A to-do item — usually inside a Project, but standalone tasks are supported. Carries assignee, due date, status, and a comment thread. Multi-assignee tasks fan out per user. - name: TaskAssignee description: Resource 'TaskAssignee' operations. - name: Topic description: Resource 'Topic' operations. - name: Town description: Resource 'Town' operations. - name: TrainingType description: Resource 'TrainingType' operations. - name: TrainingTrainer description: Resource 'TrainingTrainer' operations. - name: Unit description: >- A generic organizational grouping — the umbrella under which local centers, role groups (auto-populated by role), and private project teams all live. Mostly used by the role-assignment and visit-tracking endpoints; most integrations work with the more specific LocalCenter and Group entities instead. - name: UnitRole description: Resource 'UnitRole' operations. - name: UnitIndustry description: Resource 'UnitIndustry' operations. - name: UnitType description: Resource 'UnitType' operations. - name: User description: >- A person with a full account in the organization. Created when someone signs up through the registration form, when an admin registers them, or when an adhesion (membership application) is approved. Users hold roles, permissions, contracts, fees, family relationships, badges, and event attendances. Lifecycle: `NEW` (created, awaiting email verification) → `ACTIVE` (verified, fully usable) → `INACTIVE` (soft-deleted or self-resigned). Admins with `HR_LOCAL` or `HR_TENANT` permission can transition users through these states; users themselves can update their own profile fields and password. - name: UserApiToken description: Resource 'UserApiToken' operations. - name: UserConnection description: |- A peer-to-peer relationship between two Users in the same tenant — the "follow" / "friend" graph that powers the member directory's social features. Lifecycle: `PENDING` (request sent) → `ACCEPTED` (mutual) or rejected (deleted). Both sides can list incoming, outgoing, and accepted connections. - name: UserList description: Resource 'UserList' operations. - name: UserListLink description: Resource 'UserListLink' operations. - name: UserRole description: >- A role assignment that grants a User permissions within a specific Unit (local center, role group, project, or the whole tenant). The same User can hold many UserRoles across different units. Creating or deleting a UserRole is how admins promote, demote, or reorganize the team. See the [Permissions](https://orgo.space/docs/platform/permissions) doc for the domain × scope matrix. - name: UserUnitRoleGroup description: Resource 'UserUnitRoleGroup' operations. - name: Vote description: >- Vote Entity - Represents a question within a VoteCollection A Vote is a single question in a voting session (VoteCollection). All session-level properties (dates, status, eligibility) come from VoteCollection. - name: VoteOption description: Resource 'VoteOption' operations. - name: VoteUser description: Resource 'VoteUser' operations. - name: VoteBox description: Resource 'VoteBox' operations. - name: VoteCollection description: |- An e-voting session — board elections, by-law changes, motion votes. A VoteCollection groups one or more Votes (individual questions). Lifecycle: `DRAFT` → `PUBLISHED` (voters notified) → `OPEN` (accepting ballots) → `CLOSED` (tallied) → `ARCHIVED`. Has clone, archive, close, and CSV-export endpoints. - name: WaitlistEntry description: |- A pending application against a closed-registration event or organization — for cases where membership is capped or invitation-only. Lifecycle: `PENDING` → `APPROVED` (admitted, often with an invitation email) or rejected (withdrawn or denied). Supports bulk approve, reject, notify, and priority-reorder for queue management. - name: WaitlistPrioritySetting description: Resource 'WaitlistPrioritySetting' operations. - name: WebhookSubscription description: |- A registered HTTP endpoint that receives event notifications from Orgo. Subscribers pick which event types they care about (`user.created`, `product_payment.created`, etc. — see [Webhooks](https://orgo.space/docs/api-reference/concepts/webhooks)), optionally set a secret for signature verification, and get a delivery- log endpoint for debugging. Test-firing a subscription helps verify end-to-end connectivity before going live. - name: Widget description: |- An embeddable subscription / signup widget that lives inside a Newsletter or on an external page. Captures Contacts (with their newsletter-opt-in state) and feeds them into the audience pool. Has its own subscribers listing and public render endpoint. - name: Workflow description: |- An automation rule — "when X happens, do Y" with optional conditions and delays. Triggers include user-joined, payment-received, contract-signed, course-completed, identity-validated, and user-inactivity events. Actions include sending emails, assigning roles, updating fields, and creating tasks. Workflows can be activated, deactivated, duplicated, and test-run against sample data. - name: WorkflowExecution description: Resource 'WorkflowExecution' operations. paths: /api/v1/task_assignees/{uuid}: delete: tags: - TaskAssignee summary: Remove assignee from a task description: >- Removes a user assignment from a task. Requires PROJECT_EDIT permission on the parent project. operationId: api_task_assignees_uuid_delete parameters: - name: uuid in: path description: TaskAssignee identifier required: true deprecated: false schema: type: string style: simple explode: false responses: '204': description: TaskAssignee resource deleted '404': description: Not found links: {} components: securitySchemes: ApiToken: type: apiKey in: header name: Api-Token description: | Server-to-server authentication. Generate a token in the admin UI at **Settings → Developers → API Access**. Send the raw token in the `Api-Token` header — there is no `Bearer` prefix. Tokens can be marked read-only at creation time, in which case the API rejects any non-GET request with `403 Forbidden`. JWT: type: http scheme: bearer bearerFormat: JWT description: | Session JWT obtained from `POST /api/v1/login-check` (email + password) or `POST /api/v1/verify-login-otp` (one-time password). Send as `Authorization: Bearer `. Tokens are valid for approximately 11 days and are tied to the tenant the login was made against. ````