Hi there

THE API IS SUSPENDED UNTIL I CAN RETURN TO IMVU.


This is for developers only
Soon I will be releasing an API of my own that will ease down the process of dealing with so called internal api quirks.


If you have any other questions or need help with something as I’ve said down below, you can message me or you can join my discord (it’s still needing to be finished) but use general for everything you want:

Live yourself out I’d say, I’ll also be dropping photos and more info of the api of mine.

The main purpose of this API is serving sessions in account which you add to my API (Database) making authenticated calls to the api as easy as possible.

This post can be dramatic as it's my first ever.

So, to keep it short for those:
Add an account (Normal and TWOFA) and afterwards you can easily tell it to reauthenticate (add a new session) which u can use to your own app, or make requests to predefined routes I have added with security of the session in mind
Soon I will support manual insertion (This kinda defeats the point)

One thing I do encourage since accounts and sessions are saved in the database is to use fake accounts for those who are interested and get to use it. I do not encourage using your real accounts, just ones that have no worth to you in any means how.

It is yet a work in progress, so a lot of things can change unannounced.

I wanna add to over 80 endpoints to cover the in depth and every feature of what IMVU's api has to offer, so you can use it to full extends. But, it's main purpose is serving sessions so you can integrate those into your own project and make what you want to make.

Why I made this?
The struggles of having to remake the auth system and improve in every small or big project I had is a pain. So why not create a central place to store and automate it. Well here it is.

Is this API still a concept?
Yes and no. The API is working and routes with no asterisk have already been added and fully functional. Not everything is noted down, as I've mentioned here under, I basically want to anything the main can do on a developer (easy) scale. So, not everything may be added in a fast time frame, as I have enough time, but I still am a person and I have my needs so everything at a time.

Will you add NFT functionality into this too?

If I have the time and will to do so. Basically, I want this API to do basically anything IMVU can do itself, but then on a developer (easy) scale so u can do it within your own app with little to no effort. Whether it may be something small or big, any wish is welcome. If I find it good enough I will add it to a soon to be road map you can all view.

Every account added is bound to an API key.

API keys have a key and a secret.

Note:
1: In some routes you may have noticed a {session:number}, this is to provide a session id that was added. Users have the choice to manually choose a preferred session which they can retrieve using the list endpoint in sessions. Or they can provide 0, and it will pick a valid session for them.

By valid I mean, verify that session, if valid return it. If not, expire it and run it just as many times until you run out of sessions (that were authenticated) or it stumbles upon a valid session.

Automation has been kept in mind. Please do know that this is only intended for predefined routes that need a valid session to make those requests to IMVU. For example, session group does not offer this as it should be used to get data of a single session. However, a separate route will be added in sessions to grab the first one that's available
2: Because of integrity and all that requests can take up to 800 ms to 4 seconds. If it's higher than that, API needs to wake up second and on is always faster.

Current routes:
Things marked with (*) asterisk will be implemented before the first test release.
Things marked with (**) double asterisk will be implemented later, they're still under consideration, because of ongoing issues that need to be looked at.
--- AUTH
login (GET) => Reauthenticates an added user, useful if session expired or if u need a back-up just in case. Can be used as much as preferred, IMVU can rate limit you if you abuse this.
add (GET) => (normal and two)
--- TWO FA ---
Since, we're dealing with emails and codes. It is possible to provide accounts enforced by 2FA. In this case you have to provide a username, password, imap server, imap email, imap password. Which the API will use to grab the code, the email has to condone the requirements of being unseen, otherwise it will not work. And will mark them as flagged on opened (which is normally done). However, only do this to accounts you want to safeguard, for example: Burner ap, vip accounts etc… Can take up to 15 seconds to a minute to complete, because of the extensive operations it has to go through. But it never fails once it set up correctly. In my use case, it never failed. It will try to grab the code 5 times, and then it fails. Hence, it can take up to a minute. Usually completes within 15 seconds. If authenticated thru EMAIL since username failed. It will perform a check and rectify those invalid data. Username it won't. It's the same for every auth endpoint in the group.
--- END TWO FA---
--- NORMAL ---
Speaks for itself, requires a username, email, and password. Can take up to 4 to 6 seconds. Typically, add accounts that are not protected by TWO FA. Do not try to use this if the account has TWO FA. It will not work.
---END NORMAL---

The following routes will be added: deleting your user, imap config (edit or add), toggle two fa (needs a valid configuration from IMAP if being turned on).

--- END AUTH

--- BEGIN SESSIONS
GROUP => sessions/{username:usernameofuser}
Route: list/{auth:number} (GET) => This will list all the sessions of the given username and auth is an integer, provided you were to give a 1. It will authenticate all the sessions belonging to that account and expire and remove those that are not valid anymore. Useful if you want to check what is and what is not valid anymore. A session is valid for many requests to come, dependent on what you do. Useful if you wanna save it into a JSON file or whatever.
Route: delete (DELETE) => This will delete all the sessions belonging to that account. It will also try to log out all the sessions on IMVU and then destroy them. It will tell which have been signed out and which have not.
*Route: firstAvailable/{howmuch:number} (GET) => This route is intended to provide the route that is first available for use. This is preferred when you rely on active sessions all the time. This will return a preferred amount of sessions when available or will be capped down to the size available. Will have the same recursive order as session middleware to ensure integrity.
--- END SESSIONS
Do not confuse these 2. This one is for single session.
---BEGIN SESSION - DOES NOT USE AUTOMATIC SESSION GRABBING
GROUP => session/{username:string:usernameofuser}/{session:yoursessionid:number}
ROUTE: info/{auth:number} (GET) => Same use case as list, but this is for a single instance.
ROUTE: revoke (DELETE) => Same use case as delete, also tries to sign out the session on IMVU to render it unusable. If that fails it will still proceed to render that session as unusable on the API itself.
--- END SESSION

--- BEGIN PROFILE - DOES USE AUTOMATIC SESSION GRABBING IF PREFERRED - VERIFIES SESSION BEFORE USE
GROUP => interact/{username:string:usernameofuser}/{session:yoursessionid:number}
ROUTE => general (POST) (May need to be renamed?) => This will general allow you to edit your profile card so this includes: display name, bio, interests, looking for and relationship, it also offers a (emptyThis) value to empty fields. This only works interests and bio, as display name cannot be empty, and looking for needs to be between 0 and 4, relationship_status needs to be between 0 and 6. Basically edits your profile card.
**ROUTE => profile_pic/{crop:number} (POST) => You can either upload a file, or u can provide a base64 encoded string to upload to your profile as picture. This seems to be a bit iffy, since the server drops out sometimes but will need to be fixed regardless. This will definitely be implemented
--- END PROFILE

--- BEGIN INTERACT - DOES USE AUTOMATIC SESSION GRABBING IF PREFERRED - VERIFIES SESSION BEFORE USE
GROUP => interact/{username:string:usernameofuser}/{session:yoursessionid:number}
ROUTE => message/next (POST) => Takes a message_id (Who to send it to) and message (content of message, string only): This sends a message using IMVU's next api. Since I have no clear way of automatically determining message_id you'll have to supply them yourself for now.
Why next over classic?: Next does not provide a soft limit (hard limit is uknown), you would have to seriously spam this to get limited, but classic should be used for slow messaging, after a few you get rate limited no matter the speed if you use the classic endpoint.
ROUTE => message/classic (POST) => Takes a to_cid (integer, who to send it to, is the id of the user) you can use IMVU mafias user finder to find the cid of the user, (message) content of the message, also string only. No gifting supported.
ROUTE => join/{room:roomid} (GET) (DOES NOT WORK ON LIVE ROOMS * YET) => This allows you to join a normal room on IMVU, if you haven't been booted or blocked by the owner. Fairly simple to use. Right?
ROUTE => leave/{room:roomid} (DELETE) => Allows you to leave the room. Exact opposite of join
*ROUTE => leaveAll (DELETE) => Forces your avatar to join all left rooms. Will take a look into your room history to determine the rooms you're in. So functionality and integrity of this may be limited. Better methods added over time.
Benefits of joining and leaving? I like to introduce as many given options as I can and want. Even the little things matter.
--- END INTERACT

--- BEGIN ROOM AUTHENTICATED - DOES USE AUTOMATIC SESSION GRABBING IF PREFERRED - VERIFIES SESSION BEFORE USE
GROUP => room-authenticated/{username:username}/{session:number}/{room:roomid}
ROUTE => info (GET) => returns INFO of a room, participants, moderators, bootable users, and bootable users by owner and all that. Everything that you could possibly know about the room can be in there. Soon liked_by etc... It is being expanded as we speak. The middleware find_room will be expanded into doing this.
*ROUTE => favorite (GET) => Tries to favorite this room on your profile. Why not right? I will also add an opposite of this route called unfavorite
*ROUTE => report (GET) => Give a reason why to report this room using IMVU's reporting feature as it is now. This can be used to automatically report a room if need be. Do not abuse this feature as it could lead to termination to your (burner) account. Use this with consideration out of others and yourself. We all know that using this to falsely report any is not doing any good either.

This group will be much more extended
--- END ROOM AUTHENTICATED
*room-owner => Allows you to manage your rooms from the api. Needs a more in depth look at. Also looking to add live rooms and other things into this.
--- BEGIN ROOM MODERATION - DOES USE AUTOMATIC SESSION GRABBING IF PREFERRED - VERIFIES SESSION BEFORE USE
Before using this: For this endpoint you must be a moderator or owner of this room. Before you can use it I made the decision to actively check if you're a moderator, if not you cannot run this endpoint.

Basically, as this endpoint check if you're an owner or moderator, it will also decide who you can and cannot boot to prevent any further mistakes. This is certainly needed for cleartheroom and boot random endpoint, to avoid errors and mishaps.

Owners can boot mods
Mods cannot boot owners.
So based on your permissions, it will tell you who you can boot and cannot boot. And those 2 endpoints behave exactly the same. They will tell you who was booted and who wasn't. It will also check if that person is present and not blindly boot.

Do I have to be in the room? No, you do not have to be in the room. You can hit this endpoint whilst not even being joined or listed as a participant. Nice yeah? I think so too.

GROUP => room-moderation/{username:username}/{session:number}/{room:roomid}
ROUTE => boot/{cid:number} (DELETE) => Boots the user by cid. May add another endpoint with username. It will tell you if it couldn't boot, either because you could not do it or the user has higher or equal perms to you. Instead, it will list users you can boot who are present in that room.
ROUTE => cleartheroom/{bootmods:bool} (DELETE) => Speaks for itself. Boots everyone you're allowed to boot. Will say who it booted and who it didn't. Basically never occurs for who didn't since permissions are being checked as it goes on. Owners can choose to boot mods. So that is either a 1 or 0.
ROUTE => bootrandom/{bootmods:bool} (DELETE) => Boots a random person, usually being used for when you need to create room in your room. Since the client does not allow you to boot someone from outside if you haven't joined (classic as on next accordingly to my knowledge).
--- END MODERATION

--- BEGIN MISC - REQUIRES A VALID API KEY ONLY
GROUP => misc
ROUTE => ping (GET) => Used to check if IMVU is up from our side, also checks if the API is up. Depending how fast IMVU is will thise route return a response.

Uffff, the solution to all my problems!

When do you think the release will be?