Who this guide is for
Integrators and technical partners who connect to Eclipse to manage which teams can access which models. In Eclipse, reps usually get model access through teams, so team assignment is how you control who can see or work with a model.
What you need
- Your Eclipse API base URL.
- A valid Eclipse v1 token / session token for the environment you are calling.
- Requests are typically sent as JSON with an Authorization header using the same authentication flow your Eclipse v1 environment requires.
Authentication note
These endpoints are v1 endpoints. To call them successfully, you need a v1 Eclipse token, not just a generic API token. If you are automating this programmatically, acquire the token using the same v1 authentication flow your Eclipse environment uses. If you are unsure which authentication flow applies in your environment, work with your Orion / Eclipse contact.
API version
These paths use v1, which matches what the Eclipse application uses in this workflow.
Why read teams before you change them
When you update a model and send a list of teamIds, that list is treated as the complete set of teams for that model. Teams you leave out are removed.
Before making any change:
- Read the current teams on the model.
- Merge your additions or removals in your own process.
- Send the full final list of team IDs in the update.
Step 1: Get the teams currently on a model
Request
| Method | GET |
| Path | /v1/modeling/models/{modelId}/teams |
| Query parameter | isEditModel=true |
Example
GET /v1/modeling/models/12345/teams?isEditModel=true
What you get back
A JSON array of teams. Each item typically includes:
- id – team ID
- name – team name
What to do with it
Build the final list of team IDs you want to keep on the model. Add new teams, remove any you no longer want, and carry forward every team that should remain assigned.
Step 2: Update the model, including teams
Request
| Method | PUT |
| Path | /v1/modeling/models/{modelId} |
Example
PUT /v1/modeling/models/12345
How to build the payload
The safest pattern is:
- Read the current model by ID.
- Start from that current model payload.
- Change only the fields you intend to change.
- Set teamIds to the full final list of teams that should remain assigned.
teamIds should be an array of numeric team IDs.
Example payload shape
{ "id": 12345, "name": "Example Model", "teamIds": [12, 34, 56] }
Important
This example only shows the team-related portion of the update. Your environment may require additional model fields on PUT, so the safest approach is to use a fresh GET response as the starting point for your update.
If you omit a team ID from teamIds, that team may lose access to the model.
Team-first alternative
If your workflow is team-first, you can attach models from the team side instead of editing models one by one.
Request
| Method | POST |
| Path | /v1/admin/teams/{teamId}/Models |
Example
POST /v1/admin/teams/99/Models
Body
{ "modelIds": [12345, 12346] }
Note
Some environments may also support PUT on the same path to replace the full model list for a team. Confirm the expected behavior in your environment before using it.
At a glance
| Goal | What to call | What to send |
| See which teams a model has | GET /v1/modeling/models/{id}/teams?isEditModel=true | none |
| Change teams on one model | PUT /v1/modeling/models/{id} | full model payload plus complete teamIds list |
| Attach models to one team | POST /v1/admin/teams/{teamId}/Models | modelIds array |
Practical tips
- Read teams first before updating a model.
- Treat teamIds as a full replacement list.
- Use a valid v1 Eclipse token for v1 endpoints.
- If an update fails or access changes unexpectedly, compare the teamIds you sent with the list returned from Step 1.