チーム

1 つの組織アカウントからチーム全体に送信できます。メンバーは各自の Apple ID で参加し、グループ、端末タグ、ルーティングルールによって、誰がどのライブアクティビティと通知を受け取るかが決まります。

How it works

An organization is its own PushWard account. It has members instead of devices, and its API keys send to the members' devices. Everything is managed in the web console at console.pushward.app, where you sign in with Apple.

1. Ask for early access with the button above. Once it is on for your account, create the organization at console.pushward.app; its 14-day trial starts then. Invite people from Invites. An invite is a link, single-use or for several people, with an expiry.
2. Members open the link, sign in with the Apple ID they use in the PushWard app, and join. Ongoing Live Activities of the organization start on their devices right away.
3. Create an API key under API keys and use it like any hlk_ key. What it sends goes to every member the routing below allows.

Organization activities show up in the app as shared by the organization, also in app versions older than this feature, and count toward the member's own limit of Live Activities shown at once. Leaving one in the app mutes that slug for the member until they unmute it in the console.

Trial, seats and billing

The trial lasts 14 days, one per person, and holds up to 5 members. It has every organization feature, but members keep their own plan: the PushWard Plan comes only with paid seats. During the trial the organization can send up to 5,000 notifications a day.

A seat is one member, not a device. A subscription starts at 3 seats, the organization can have as many members as it has paid seats, and each paid seat gives that member the PushWard Plan while they hold it. Sending is pooled: 5,000 notifications a day per seat, shared by the whole organization. Seat changes are prorated.

The subscription is bought and managed in the console, never in the iOS app. Paddle.com sells it as our reseller and merchant of record, so the invoice comes from Paddle, which also handles VAT and sales tax. Refunds follow the refund policy.

Roles

Every member receives what the organization sends and manages their own devices and mutes, whatever their role.

Every change made in the console lands in the Audit log, with who made it and when.

Devices and mutes

Under My devices every member decides which of their devices take part. A device switched off gets nothing from the organization: its Live Activities end, and notification pushes skip it (the inbox entry still arrives). Members can also mute slugs, such as ci-*, for themselves only.

Groups and device tags

A group is a set of members, such as oncall or backend. A device tag marks single devices, such as wall for the iPad on the office wall. Names are lowercase letters, digits, - and _, start with a letter or digit, and are up to 40 characters. An organization holds up to 50 groups and 50 tags.

Deleting a group or tag removes it from every routing rule, target and key limit. A rule or target left with nothing reaches nobody, so an ongoing Live Activity aimed only at a deleted group ends.

Routing rules

Rules decide who gets what. Each rule has a slug pattern (exact, or a prefix ending in *), applies to Live Activities, notifications, both, or widgets, and allows some groups and tags. Rules are checked in order, and the first one whose pattern matches and that applies to that kind of send decides:

• A member in one of the rule's groups gets it on all their devices, and a device with one of the rule's tags gets it whoever owns it.
• No rule matches: everyone gets it.
• A rule that allows no group and no tag: nobody gets it.
• Notifications match on activity_slug, or on source when they have no activity.

A rule change applies to ongoing Live Activities at once: they end on devices that lost them and start on devices that gained them. An organization holds up to 100 rules.

1. deploy-*   activities and notifications   group oncall, tag wall
2. billing-*  notifications                  group finance
3. noisy-*    notifications                  nobody
   everything else                           everyone

Targeting a send

An organization key can narrow a single send with target. It works on POST /activities, PATCH /activities/{slug}, POST /notifications and POST /notifications/scheduled. A target narrows what the routing rules allow; it never reaches anyone a rule keeps out.

curl -X POST https://api.pushward.app/notifications \
  -H "Authorization: Bearer hlk_YOUR_ORG_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "title": "db-1 disk at 95%",
    "body": "Paging on-call",
    "level": "time-sensitive",
    "target": {"groups": ["oncall"]}
  }'

• Names are matched without regard to case. An unknown name fails the whole request with 422 org.target_unknown, which lists every unknown name.
• A Live Activity keeps its target. A later PATCH with a new target replaces it and "target": null sends it back to everyone the rules allow; devices that lose it end it and devices that gain it start it. A POST to an existing slug without target keeps the stored one.
• A scheduled notification resolves the names when you schedule it, so renaming a group later does not matter. Who is in a group is read when it is sent, and a group deleted by then reaches nobody. Once every group, tag and member the target names is gone, the schedule fails with target_deleted instead of being sent, without counting toward your quota. A repeating one stops, unless its target names a member who can be invited back: then only that send is skipped.
• A notification that nobody receives is still stored, and the response says "pushed": false with "delivery": "none" and "reason": "no_apns_token", as for an account with no devices.

The CLI takes --target-groups, --target-tags and --target-members, and --no-target on activity update (see CLI). In the MCP server, create_activity, update_activity, create_notification and create_scheduled_notification take a target argument, and update_activity takes clear_target.

Keys limited to groups and tags

When you create a key in the console, Reaches can limit it to some groups and tags, for example a key for a team's own tooling. The limit is set once; to change it, create a new key. Such a key:

• sends only inside its groups and tags. A send with no target goes to all of them, a target outside them is refused with 403 integration_key.target_denied, and it cannot name members or clear a target;
• sees only activities sent inside its groups and tags. GET /activities leaves the others out, and reading, changing or ending one of them answers 404, exactly as for a slug that does not exist. Activities sent to everyone are outside every limit, and so are activities whose groups and tags were all deleted, so a limited key does not see those either;
• cannot reuse a slug taken by an activity it cannot see. Slugs are unique per organization, so creating one answers 403 integration_key.target_denied. A notification naming such an activity in activity_slug gets 422 notification.activity_not_found.

If all of a limited key's groups and tags are deleted, it sees nothing and every send is refused with 403; create a new key.

The activity_slugs limit of a key (see permissions) still applies on top.

Widgets and email

A key made in the console can also carry widget and email permissions, as on a personal account.

Email goes to recipients the organization manages. A key with email permission that is not limited to groups and tags adds and removes them through /emails/recipients; each recipient confirms their address before the first message, and sends count toward the organization's email quota.

Errors